Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - d3x0r

Pages: 1 2 3 [4] 5
Programming with Blackvoxel / Re: How hard could smoothing be?
« on: October 27, 2014, 03:19:43 am »

Does culling must be done at world level ? In some parts, sectors need to be processed independently to the existence of a world.  So, your proposition of an independent class is an efficient idea to clean the mess.

But we are tempted to say : don't mangle your head too much with that.

Because what is on our roadmap for future is making face culling completely integrated with rendering phase.

Yes, making that could be a very, very bad choice in some ways because it can add significant overhead to the main thread.

So, why we plan to do it ? Let's explain the actual system and why it could be better.

Keep in mind that Blackvoxel made very specific game choices. It's MVI engine cause massive load on rendering. Also, vehicles like airplane needs very quick refresh of sectors.

The Blackvoxel Team
Right; it looks like something that should be part of the render path, with the same dirty flags, so if the display lists are built already, just run those, otherwise do the required updates.

Also, the game is maxed at 17-19%... would be interesting if more threads could be started to process things like water.  looks like there's only 1... and the renderer doing work.

Re the PartialCulling... when it comes time to check the edges... Oh I see... partial culling is cleared as near sectors are found so it doesn't have to do all sides every time a new near sector is added.

Programming with Blackvoxel / Re: How hard could smoothing be?
« on: October 27, 2014, 03:09:49 am »
The problem come from the collision detection system. That's what is making in fact the effectiveness of the body size.

Anyway, whatever the way, the collision detection must be redone if you want to change voxel size.
Increasing the detection distance appeared to be necessary because with some ratio, the player was unable to get voxels just at it's feet.

...but as a variable it's not been a huge performance hit.

Not only a variable, but also using division/multiplication instead of shifting ... unless you would be limited to power of two ratio.

Sure, it's not huge, but it's always good to avoid when possible.  :)
again .. I didn't change any operators... defined the number of bits a voxels is...
certainly changing just how it's rendered by moving the eye and changing the body size would be a smaller change.

but voxel size should be a property of a ZVoxelWorld... (like space engineers, the base world is 'Platform' and is aligned square with the universe, other 'worlds' would be implemented for small/large ships which have a translation/rotation matrix associated with them... and a different rendering size)

just played a demo of another game that's voxel based called 'Masterspace' a starforge clone kinda, but with much better game dynamics than starforge ended up with... land is smoothed, but when you re-place blocks you can put them back out as square units, so buildings built with mined resources are square....

Programming with Blackvoxel / Re: How hard could smoothing be?
« on: October 26, 2014, 06:57:56 pm »
Neither of these routines use FaceCulling or 'data' variable associated with the face culling faces... so I think the faceculling save/load isn't working...

Compress_FaceCulling_RLE(UByte*data, void*stream)
     ... actual = OtherInfos[p];
Decompress_FaceCulling_RLE(UByte*data, void*stream)
    OtherInfos[p] = read;

Programming with Blackvoxel / Re: How hard could smoothing be?
« on: October 26, 2014, 03:29:13 pm »
Is sector based PartialCulling really worth even having?
How often is an entire side of a thing opaque?
Culling needs to not be a world property; but really more something associated with the renderer; because only the renderer (and save file) is a consumer of cull data.  It certainly makes sense how it currently is that nothing(except game container) knows about the renderer... I started passing the game environment as initializers so classes could get the renderer; and added some culling methods to renderer... but maybe ZVoxelCuller should be a utility class that's associated with/retrieved from the renderer, and then pass that.  ZVoxelCuller would look more like an interface with

ZVoxelCuller( ZWorld &world );

InitFaceCullData( sector );

CullSector( sector, internal/edges);
CullSectorInternal( sector );
CullSectorEdges( sector );

and CullSingleVoxel( sector, (x,y,z/offset) );

started ending up with circular references, and things that had static members of thigns like SectorStreamLoader has a SectorCreator, which allocates sectors, and needs the culler (sounds like color)....
I'm enjoying mangling your code :)
I'm going to make some other forks and clean up portions of this, like ZMatrix modification to Camera/PlayerPhysics
also right now; draw_left actually draws the right side; and draw_right draws the right side...
this is a texture labeled according to clipping output...
the letters are oriented up on the sides... and the A for 'above' is up-right if looking from the back to the front.   if you like bypass the 'DRAWFACE_LEFT' there will be a hole for the 'L' side...  either that or forward/backward are reversed... or above/below... if any of these were wrong in the current... render matrix, then the RTFM cube would have backward text on some sides... and an original version does the same thing. (I'm pretty sure.... mine's totally broken right now, going forward with ZVoxelCuller utility class...)
Disrelated to the thread, but was thinking about other objects... I guess ZVoxelWorld is where I should add a ZMatrix for its current orientation, and give it a small sector size... was going to make ZVoxelSector instances that were standalone for large object models... (an airplane instead of a box with an airplane picture for instance), but maybe it makes more sense to instance worlds

Programming with Blackvoxel / Re: How hard could smoothing be?
« on: October 26, 2014, 11:52:54 am »
I see what you did...
just moving the eye position can shrink the world... but then the player body doesn't match the eye .. and if I have a 2 block hole in a wall I can go through the wall even though my eyes are staring at blocks.

Detection distance.... should stay the same I guess... just has 64x the blocks in the same space...

like I should still be able to dig the same distance as 6 blocks from before... but now it's 24 blocks deep instead

Programming with Blackvoxel / Re: How hard could smoothing be?
« on: October 26, 2014, 10:12:16 am »
Ya but you're shrinking the character too; the point was to add more detail to the world... not just shrink the virtual render size :)  increases the sector count visible though I suppose; but that's just extending the sphere selector thing

It's basically the same mod I did... as a const int variable it's gonna compile away anyway... but as a variable it's not been a huge performance hit.

eye position should be 256

So the inner-sector culling routine is working.... I'm gonna have problems with the inter-sector culling though... the inner-sector had a nice 3x9 block of sectors it was working with... I'm thinking of redoing the seam culling with a 2x3x3 row of voxel references.... need to recover blocks that are near the blocks that are near also...

pretty sure I can do this without the 8 corner cubes in the 3x3x3 set around a point.

was also considering how to implement that culling data is 8 or 32 bits (save version?) but would like to retain so renderer could be applied per sector... but keep the optimal 6 bit culling for render basic...
not sure that a reference looking for Xoffset Yoffset etc is any faster than doing the shifts... since the coorindate has to be shifted to index the array anyway...

Programming with Blackvoxel / Re: How hard could smoothing be?
« on: October 26, 2014, 12:45:01 am »

We have seen in the video that you are using Visual Studio. We assume you are using Gcc/Gdb with it?

The Blackvoxel Team
Nah, using cmake, which spits out makes appropraite for visual studio, I also use open watcom on the side... watcom, gcc and msvc all catch different errors; but cmake allows one make system to support them all...
SDL also uses cmake scripts...
It took a long while; but cmake 2.4 was actually usable.
It's actually not marching cubes...
Was reverting it so I could sway between Render_Basic and Render_Smooth by making most of renderBasic be REnder_Interface, and a virtual 'render' function... but it's just based on existing culling flags
Code: [Select]
     // example excpetion...
     //     // render more complex interpretations
     //  else
     //      //basic, draw  diagonal slope.
unfortunately because near sectors aren't always present, and i haven't fixed up the mating clipping updates, on sector boundaries I get false lacking cubes...

and I broke saves because I expended the clipping data from a byte to a long; needed 12 more bits in addition to the original 6 facedraw bits...
and I think I might need all 8 more for the corners ... 26 total... representing the cube of voxels around a center voxel

re the floating land issue; it started showing up when I shrank the block size, so I figured it was just able to see so many more sectors above it that it actually ended up just treating every sector as 'need to fill' ... but it may be a cube that failed to be ejected properly... because again the scale of the world and that doesn't match what it was designed to be..
was just curious if it was something you had seen or something I had messed up... I'll revert some at some point and see what I did.

Programming with Blackvoxel / How hard could smoothing be?
« on: October 25, 2014, 02:20:50 pm »
Well... it was a lot harder than I thought...

work in progress; maybe

inner corners are unsmoothed... just smooths the outer edges.

Have many corner cases that have multiple solution paths... light right now single blocks and single rows of blocks don't smooth either....

and I have a broken corner that could be better; not to mention all the directions that are yet missing.

was going to map textures on diagonals such that if it's a top & left visible, to show the top and left side of the texture, so the diagonals would get an extra line; right now all left & anything is left and any right & anthing is right and any forward & any is forward and same for back; sorta, top&((right/left)&(back/front)) is top....

Suggestions / Re: 3D terrain
« on: October 25, 2014, 02:13:58 pm »

It's a very interesting idea. :)

We will look at the problem.

The Blackvoxel Team
Had a viewer for elevation map that would scroll sub-sections paged in dynamically basically...
had issues mating edges with sectors that didn't load yet... or depending on the order to approach the sector the boundary would be generated differently.... have to save the seems separately I guess.. and even then the diamond square plasma isn't really condusive to that sort of operation....

Suggestions / Re: 3D terrain
« on: October 24, 2014, 02:51:05 pm »
I lost some of what I had....
I did have a US national map with elevations in meters in 200x200m resolution; was only like 40M

I guess they have 1m resolution now... can add a region type 'external bitmap' or something to the world map...

Why do I get terrain blocks that appear high in the air?  is it cause a sector is 1/4 the size in mine?  I mean what stops the generator from generating sectors that are in the air?

at the 200x200m resolution I was going to use the coordinates of the corners and make a plasma grid fill or some perlin noise something...

Programming with Blackvoxel / Re: Voxel pixel selector box, render offset
« on: October 24, 2014, 02:29:38 pm »

Yes, compilers are replacing some divide by shift. But there is a trap...  ;)

Look at this program:

Code: [Select]
    int a = -64, b, c;
    b = a / 256;
    c = a >> 8;
    printf("Divide : %d\nShift : %d \n",b,c);

Oh I see... well I didn't change any operators....
that's interesting...
that does solve some boundary issues (or cause if not recognized)

Programming with Blackvoxel / Re: Voxel pixel selector box, render offset
« on: October 23, 2014, 04:40:54 am »
Hi d3x0r,

If you changed code for conversion, there is a little trap in the player to voxel coordinate conversion. If you replace shift by division it won't work because result is different on some values. Try with negative value -64.0, division(/256.0) and shift(>>8) won't give the same results. That could be enough to mess a lot of things.
The shift conversion was used to avoid having two "0" voxels ( 64.0 and -64.0 position would have given the same result : 0).

Another problem if you replaced the "256" constant in code is that this number is also the number of voxels in a zone. The zone is the unit for the generator to choose the kind of landscape that will be generated. That's used in some code in the generator ("ZWorldGenesis.h" and .cpp).

The Blackvoxel Team
Right; I actually ended up replacing '256.0' so it missed all the integer versions... there are a few other places that 256 is used...

I ended up making a separate global varible "VoxelSizeInBits" which then expands and creates the actual voxel size... then I had the number to fixup the shifts too.

'12' and '16' are also rarely used numbers, these were shifts from world space to sector (world_bits + ZVOXELBLOCSHIFT_[x/y/z]) and a few places where it was just '8' from world space to voxel coordinate.

most compiles generate shifts if the constant is a power of 2 in a multiply or divide when generating optimizations; at least MSVC and GCC do.

-64 = 0x(ffffff)C0
dividing or shifting a signed variable results in the same value
if the value was an unsigned integer the shift would give the wrong result because it would not be sign extended, and would be 0 filled at the top instead...

Made a fork on github...
I would try to make a pull request to sync some of the stuff; (cmakelists for instance) but I mangled(touched/modified) a lot of sources in the update to use SDL2.
I don't know if you get to see forks on github
My original changes were from the source download, which was behind the sources on github... hmm maybe I can fix that... otherwise I think I end up losing some changes...

Well at least there isn't a lot in code conflicts... (fixed reversions)

if normal selection fails, I was using the same raycaster and shortening the max iterations; then realized I just had to scale forward by world voxel size * (6), get the voxel that point is in and draw voxel selector in air... and set that it collided so click can set the block... want to add like shift-scrollwheel to change the distance of that block... but still need to fix scrollwheel events in SDL2 port.

Programming with Blackvoxel / Thoughts on large body collisions?
« on: October 22, 2014, 11:18:13 am »
I ended up breaking collisions by shrinking the world voxel size and keeping the same player size.   I see that you built several planes to represent the character at various levels and an axis through the center.

but with small blocks, 3 or 4 blocks can fit in the spaces... so as long as the voxels that aren't in those planes aren't there, you can pass through it...

So I was considering taking the points of the forward and back planes and iterating through the voxels between them... any thoughts?
Was just now considering instead iterating the central axis and normals along the line.... so the character now is slightly larger than 1 block (6 bits; 64 pixels) so most of the collision stuff works... if I dig a 3 wide 1 deep trench in the ground, it works to keep the feet within it... but if I built bars across the path, can go through a lot. 
Also some single blocks on just the ground I can go through... maybe I end up going around it...

trying to make an argument for only needing to check +/-1 x and +/-1 z from the center axis... character is say 8 blocks high now... would be 40 voxels to check for collision... but only 2 lookups the rest can be iterated through.

Programming with Blackvoxel / Re: Voxel pixel selector box, render offset
« on: October 21, 2014, 03:28:56 pm »
Fixed that; I ended up missing searching headers for '256' and '128' (and shifts....) but most important there was a translation of player position to player sector position that was not updating correctly... so every sector block was outside of distance and qualified for ejection.

much more stable now... (well as stable as before I started mangling it with a global setting for block size)
really want to make it more like an object setting ala Space Engineers

Programming with Blackvoxel / Re: Voxel pixel selector box, render offset
« on: October 21, 2014, 08:19:56 am »
Ehm what?
I have no idea what you are trying to to say. Are you discussing the BV source code or some other code?
What is a voxel pixel?
Sorry I don't know your dictionary.  Voxel pixel is probably a redundant statement and should just be voxel... voxel block?

Of course I'm talking about BV code.
I ironed out a few more issues with changing 256 to a variable... there was a few place where shift operators were used.  Fixed the ZSectorSphere (which was actually IsPointVisible, which I broke by not using TransformParams class) usage so correct 'distant' things are rendererd.... there's also a near render ... I know because I had one working and not the other.

Now most everthing is good until I get to the first random land sectors, and I have sectors appearing in air, and sectors rendering and then not rendering and I'm just sitting still...  what class/function renders the first random landscapes? 

World_Genesis; and various functions there.  got it.... still don't know why.... I assume it's some base offset based on height map as a unit of real space?  something I dunno

Pages: 1 2 3 [4] 5