Voxelstein3D is coming along nicely, but I have a few technical things to ask:
1.) Seems like sprhitscan does not work correctly with scaling. The scale is not taken into account when inverse-transforming the ray direction. Adding this seems to fix it: v.x /= (spr->s.x*spr->s.x + spr->s.y*spr->s.y + spr->s.z*spr->s.z); v.y /= (spr->h.x*spr->h.x + spr->h.y*spr->h.y + spr->h.z*spr->h.z); v.z /= (spr->f.x*spr->f.x + spr->f.y*spr->f.y + spr->f.z*spr->f.z); Please correct me if this is wrong.
2.) What is the encoding of "vis" in kv6voxtype? I'm having a hard time following its logic from the source. Also, is it used for determining which faces of cubes are rendered?
3.) I can't get drawpolyquad working correctly *EDIT* Ok, nevermind, it doesn't use alpha.
Edited by hansk at
Awesoken at
Re: Voxlap coding questions
First of all, I'd like to say it's great that you are working with Apegomp/ConsisentCallsign. Your questions show that you are deep into the code and that you know what you're doing. You are the first person to get this far with Voxlap since Tom : )
You are probably right about sprhitscan(). It looks like I have test code in voxed, but voxed can only scale sprites equally on all 3 axes.
The lower 6 bits of vis determine which sides of each voxel are visible. Each bit represents one of the faces:
Bit 0: x- (left) Bit 1: x+ (right) Bit 2: y- (forward) Bit 3: y+ (back) Bit 4: z- (up) Bit 5: z+ (down)
The bits are set to 1 for any side where the voxel that is exposed to air. Vis is used for back-face culling. What may be confusing to you is how I use it to speed up the rendering of bounded rectangles: I take the logical and of vis with the (up to 3) face directions that you could potentially see. If the result is 0, then the rectangle is skipped. The result can also help to reduce the size of many rectangles.
Correct - drawpicinquad() and drawpolyquad() as written do not process alpha.
hansk at
Thanks! It takes quite a few memmoves to copy the data around, but now I can finally modify sprites :)
Edited by hansk at
ConsistentCallsign at
Voxels 1 - Polygons 0 ;D
hansk at
Hey Ken, I'm in the progress of adding streaming to allow bigger maps. I have a question about your memory allocator:
I need to allocate a big block of memory that will be shared by multiple columns (doing it column by column is just too slow). What exactly do the vbits contain and/or how should I modify them so the columns can later be dealloced independently again?
Thanks.
Awesoken at
Each bit of vbit[] represents 32 bits of vbuf[]. A bit value of 1 means its respective dword of vbuf[] is occupied. When you call the voxalloc() function, it searches the vbit[] array in circular fashion for a string of 0's that can fit the requested length. If it doesn't find any (i.e. when the pointer (vbiti) returns to its starting position), then you get the dreaded "vbuf full" message. No garbage collection is performed. Memory is allowed to become fragmented, although new blocks are always allocated immediately after an occupied block.
Voxel streaming seems like an awfully ambitious project. I'm not sure there's a fast solution unless you are willing to figure out how to modify V5.ASM to support wraparound. You should also know that when you modify columns, you need to refresh their neighbors because different parts of it may be exposed. Only exposed colors are defined. If you attempt to render a column that isn't compiled correctly, you will get bad colors and possibly a crash.
You know, it's not out of the realm of possibility that I create a higher resolution version of Voxlap that takes advantage of multithreading. That might not be for a few months. Still, if I should do that, it would render your work obsolete ; )
hansk at
Awesoken said at
Each bit of vbit[] represents 32 bits of vbuf[]. A bit value of 1 means its respective dword of vbuf[] is occupied. When you call the voxalloc() function, it searches the vbit[] array in circular fashion for a string of 0's that can fit the requested length. If it doesn't find any (i.e. when the pointer (vbiti) returns to its starting position), then you get the dreaded "vbuf full" message. No garbage collection is performed. Memory is allowed to become fragmented, although new blocks are always allocated immediately after an occupied block.
Thanks, makes sense. And seems that voxdealloc reads the actual column size for resetting the bit string. This means I don't actually need to change anything, yay :D
Voxel streaming seems like an awfully ambitious project. I'm not sure there's a fast solution unless you are willing to figure out how to modify V5.ASM to support wraparound. You should also know that when you modify columns, you need to refresh their neighbors because different parts of it may be exposed. Only exposed colors are defined. If you attempt to render a column that isn't compiled correctly, you will get bad colors and possibly a crash.
I'm not sure what you mean by wraparound, maybe we are talking about different things. By streaming I mean copying columns from another vxl into one end of the board and shifting the existing columns toward the other end.
http://194.79.17.244/temp/infiniteforest.gif
I have tested it in one direction and it does have a performance impact, but it's still usable. I generate a separate lookup file for column offsets to avoid seeking through the vxl file, and I'm thinking about storing some mip levels on the disk as well. Also it should be possible to keep a few boards fully loaded in memory (memory is cheap these days :))
The issues you talk about, I'm not sure if they would happen when the boards are designed to join together (and special care is taken when modifying voxels at the border). The VXL data doesn't store any face-visibility info like KV6 I hope?
EDIT: Ok, seems higher mip-map levels don't always turn out that great, they need some additional updates... EDIT 2: Streaming in x-axis is about 3-4 times slower because of data alignment (need to move each row separately). Also mip maps create plenty of problems :-\
You know, it's not out of the realm of possibility that I create a higher resolution version of Voxlap that takes advantage of multithreading. That might not be for a few months. Still, if I should do that, it would render your work obsolete ; )
That's great to hear ;D I am a pretty impatient person though, we will have to think about this ;)