
Voxel Help!
#1 Posted 05 January 2012 - 07:14 PM
This post has been edited by s.b.Newsom: 05 January 2012 - 11:44 PM
#2 Posted 05 January 2012 - 11:42 PM
(Top: BUILD, Bottom: SLAB6) The bottom screenshot is higher definition because it was pre-voxel optimization.

EDIT: Nevermind, I looked very carefully through this thread and saw the 'replace palette and convert colors' and it actually turned out quite nice without changing the colors to much.


This post has been edited by s.b.Newsom: 06 January 2012 - 07:25 PM
#3 Posted 29 December 2013 - 07:29 AM
I made a little list

aspect ratio of voxel are not the same if cstat is 0 or 16, seems correct only when the voxel are wall aligned
Flip x or y (ctat 4 and 8) dont works
structure members roll and pitch dont works
and what about voxel implementation in polymer, even without lighting or a lighting system that work like slab6 ?
I noticed that the display of voxels (when they are not too big) was very fast compared to the 3d model, it would be great if these bugs are fixed !
#4 Posted 29 December 2013 - 12:10 PM
edit:
Don't forget about this, https://sites.google...site/duke3dvmp/ I've got the Queen and Cycloid finished now too.
This post has been edited by Drek: 29 December 2013 - 02:01 PM
#5 Posted 10 January 2014 - 01:11 PM
Muelsa, on 29 December 2013 - 07:29 AM, said:
As a bit background, from r1908:
r1908 said:
So if I'm not mistaken, they were "thin" for any cstat before. The decision to make them have proper aspect for wall-alignment only was deliberate: it mimics normal sprites. That's most noticeably if you cycle alignments on a wall switch.
Quote
Well... I guess that rectangular transforms are doable (floor-alignment doesn't work too, btw), but I don't feel like coding voxel functionality ATM.
Quote
That's another story: arbitrary rotations around an axis that's not perpendicular to the ground are an exclusive domain of the GL renderers. In my opinion, since voxels are mostly a classic feature, there's no point in implementing pitch/roll as that would make the GL renderers have more voxel features than classic. I recall Hendricks disagreeing with that position, though.
#6 Posted 10 January 2014 - 05:55 PM
Helixhorned, on 10 January 2014 - 01:11 PM, said:
It's the exclusive domain of models at this point in time. I don't see why pitch/roll couldn't be implemented in Classic too, theoretically. Since voxels already exist in 3D space, you would rotate the vectors along which the voxel squares are drawn, not the squares themselves. This would work like my G_ScreenText rotation code:
void G_AddCoordsFromRotation(vec2_t *coords, const vec2_t *unitDirection, const int32_t magnitude) { coords->x += scale(magnitude, unitDirection->x, 16384); coords->y += scale(magnitude, unitDirection->y, 16384); }
vec2_t size = { 0, 0, }; // eventually the return value vec2_t origin = { 0, 0, }; // where to start, depending on the alignment vec2_t pos = { 0, 0, }; // holds the coordinate position as we draw each character tile of the string vec2_t extent = { 0, 0, }; // holds the x-width of each character and the greatest y-height of each line const vec2_t Xdirection = { sintable[(blockangle+512)&2047], sintable[blockangle&2047], }; const vec2_t Ydirection = { sintable[(blockangle+1024)&2047], sintable[(blockangle+512)&2047], };
switch (t) { case '\t': case ' ': case '\n': case '\x7F': break; default: { vec2_t location = { x, y, }; G_AddCoordsFromRotation(&location, &Xdirection, origin.x); G_AddCoordsFromRotation(&location, &Ydirection, origin.y); G_AddCoordsFromRotation(&location, &Xdirection, pos.x); G_AddCoordsFromRotation(&location, &Ydirection, pos.y); rotatesprite_(location.x, location.y, z, angle, tile, shade, pal, orientation, alpha, x1, y1, x2, y2); break; } }
I've been thinking about sending Ken an email discussing my idea and seeing what he thinks. I'll need to work on voxels at some point... Polymer needs them for SW.
#7 Posted 10 January 2014 - 06:39 PM
Seeing how voxels are being used more and more in Duke 3D mods i think it would be worth the time for some voxel related coding to be added.
#10 Posted 28 January 2014 - 08:52 AM
Muelsa, on 28 January 2014 - 08:13 AM, said:
mdsprite.c
Is this going to see it's way into Eduke32? Or will Il need to build my own binaries if I want to use it?
#11 Posted 28 January 2014 - 09:01 AM
Drek, on 28 January 2014 - 08:52 AM, said:
I dont now... i hope

#12 Posted 28 January 2014 - 11:36 AM
Muelsa, on 28 January 2014 - 08:13 AM, said:
Cheers to getting your feet wet with the EDuke32 source code. I'll comment on the actual patch shortly, but first a couple of "soft" issues.
- We prefer to receive changes in patch/diff form against a reasonably recent SVN build. If you have checked out the source using SVN, all you need to do is running
svn diff some-file-you-changed > name-you-give-the-patch.patch
If you have multiple changed files, you can list them manually or let them expand by the shell (like MSYS's bash, not CMD.exe).
- This also makes it unnecessary to mark changed lines in the source -- it's clear in the patch
- I'm pretty pedantic about coding style -- whitespace, braces, etc. It's usually best to try to follow the style of the code you're changing. There's no official coding style guide, and other members may have different views.
That said, here's a cleaned up patch for reference and further discussion:
diff --git a/eduke32/build/src/mdsprite.c b/eduke32/build/src/mdsprite.c index 230cdb5..a6d9380 100644 --- a/eduke32/build/src/mdsprite.c +++ b/eduke32/build/src/mdsprite.c @@ -3221,15 +3221,16 @@ int32_t voxdraw(voxmodel_t *m, const spritetype *tspr) m0.x = m->scale; m0.y = m->scale; m0.z = m->scale; - a0.x = a0.y = 0; a0.z = ((globalorientation&8)?-m->zadd:m->zadd)*m->scale; + a0.x = a0.y = a0.z = 0; - //if (globalorientation&8) //y-flipping - //{ - // m0.z = -m0.z; a0.z = -a0.z; - // //Add height of 1st frame (use same frame to prevent animation bounce) - // a0.z += m->zsiz*m->scale; - //} - //if (globalorientation&4) { m0.y = -m0.y; a0.y = -a0.y; } //x-flipping + if (globalorientation&8) //y-flipping + { + m0.z *= -1; + a0.z += 1; + } + + if (globalorientation&4) //x-flipping + m0.x *= -1; f = ((float)tspr->xrepeat)*(256.0/320.0)/64.0*m->bscale; if ((sprite[tspr->owner].cstat&48)==16) @@ -3260,9 +3261,8 @@ int32_t voxdraw(voxmodel_t *m, const spritetype *tspr) bglDepthRange(0.0,0.9999); } bglPushAttrib(GL_POLYGON_BIT); - if ((grhalfxdown10x >= 0) /*^ ((globalorientation&8) != 0) ^ ((globalorientation&4) != 0)*/) bglFrontFace(GL_CW); else bglFrontFace(GL_CCW); - bglEnable(GL_CULL_FACE); - bglCullFace(GL_BACK); + if (grhalfxdown10x >= 0) + bglFrontFace(GL_CW); bglEnable(GL_TEXTURE_2D);
Neutral remarks:
- Removing "((globalorientation&8)?-m->zadd:m->zadd)*m->scale" is OK as far as I can see, 'zadd' isn't used in voxels, as it's not a valid voxel DEF token.
- By itself, x-flipping seems fine
Criticism:
- Y-flipping isn't consistent with how normal sprites behave. In your implementation, assuming that the sprite is on the ground, the topmost point always ends up to be 16 PGUP units above the ground.
- You disable culling of back faces. That's arguably a matter of taste, but it's good style to change not too many things at once. By the way, the code commented in /* ... */ should do the right thing -- cull the faces of the proper orientation for all combinations (flipping x mirror).
And of course, I would strongly prefer if flipping were implemented for classic then, too. I'm fine with committing Polymost-only flipping now and keep classic for later though, as long as people understand the implications.
#13 Posted 28 January 2014 - 12:32 PM

#14 Posted 28 January 2014 - 10:23 PM
Helixhorned, on 28 January 2014 - 11:36 AM, said:

Helixhorned, on 28 January 2014 - 11:36 AM, said:
Not sure i am understanding this... need to add a z offset value ? and is this realy a good things ?
Helixhorned, on 28 January 2014 - 11:36 AM, said:
I am not yet familiar with these opengl fonctions.. not sure i'am done the right thing, but i am sure we can made a lot of thing to make eduke more powerfull. I take this opportunity to ask why MAXSPRITESONSCREEN are only 4096 since the engine can draw more than 16000 sprites ? if it is a performance issue, why not just hide all sprites that are not in the field of vision of the player ? or just let modders decide how many sprites they want to display ? i think this freedom is important...
LeoD, on 28 January 2014 - 12:32 PM, said:

I think there is no reason to believe it can't be done !
#15 Posted 28 January 2014 - 10:44 PM
Muelsa, on 28 January 2014 - 10:23 PM, said:
16384 sprites is the total number that can exist in a "game state" at any one time. Maps can store that many sprites in their data structure. 4096 sprites refers to whatever is in the player's field of vision, as you suggest.
#16 Posted 28 January 2014 - 11:17 PM
Hendricks266, on 28 January 2014 - 10:44 PM, said:
That the point, when they are more than 4096 sprites, the engine automatically hide all other sprites, using the sprite Id orders, i suppose,... He dont care if sprites are realy actually "on screen" or behind the player. So MAXSPRITEONSCREEN is not max sprite on screen, is maximum sprites the engine can draw in the same time.. even if they are not in the player's field of vision...
edit :
Maybe is better.. culling back face still enabled, and works even with flipped shapes...
- if ((grhalfxdown10x >= 0) /*^ ((globalorientation&8) != 0) ^ ((globalorientation&4) != 0)*/) bglFrontFace(GL_CW); else bglFrontFace(GL_CCW); - bglEnable(GL_CULL_FACE); - bglCullFace(GL_BACK); + bglEnable(GL_CULL_FACE); + if ((grhalfxdown10x >= 0) ^ ((globalorientation&8) != 0) ^ ((globalorientation&4) != 0)) bglCullFace(GL_FRONT); else bglCullFace(GL_BACK);
This post has been edited by Muelsa: 28 January 2014 - 11:38 PM
#17 Posted 29 January 2014 - 09:54 AM
Muelsa, on 28 January 2014 - 11:17 PM, said:
Yes.
Quote
No, on-screen sprites outside the FOV or behind the camera are culled relatively early.
Quote
Yup, that's what I was driving at. That leaves the z offset. Here's what I mean:

#18 Posted 29 January 2014 - 11:11 AM
Helixhorned, on 29 January 2014 - 09:54 AM, said:
I should explain this a bit more in detail, I guess. Build proceeds like this: first, sector geometry is drawn. This is done by starting with the camera position and going "outwards", collecting sectors in the process. Each time a sector is collected for drawing, its sprites are collected for later, as they are drawn after the map geometry. So, already here you could filter out some sprites; it's here that the MAXSPRITESONSCREEN limit matters. Also this part differs between the GL modes and classic to account for stuff like models: see scansector() vs. polymost_scansector().
When the sprites are ultimately drawn, some may be thrown out as well, e.g. because it's determined that some cover an area outside the screen. Here, the limit doesn't matter anymore, of course. For example, see classic's drawmasks().
I don't think there's really need to increase the limit beyond 4096.