Duke4.net Forums: Voxel Help! - Duke4.net Forums

Jump to content

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

Voxel Help!

User is offline   thatguy 

#1

I think I got everything down in terms of turning my poly into a model, but now I want to know if the conversion process uses the UV texture/material accompanied with the model to create the colors/texture of the voxel model? RIght now I have a texture on the model but when it's converted it turns out white. Do I have to paint it manually in SLAB6 or the like?

This post has been edited by s.b.Newsom: 05 January 2012 - 11:44 PM

0

User is offline   thatguy 

#2

Scratch that, got everything converted and viewable in Slab6. The only issue now is that it looks like the palette looks all effed up in BUILD. Do I need to create a new palette and set the voxel to use it?

(Top: BUILD, Bottom: SLAB6) The bottom screenshot is higher definition because it was pre-voxel optimization.

Posted Image



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. :unsure:
Posted Image

This post has been edited by s.b.Newsom: 06 January 2012 - 07:25 PM

0

User is offline   Muelsa 

  • Bad Mother Fucker

#3

I currently works on a cool project, and I like to know if there is hope for an update of the voxel rendering in EDuke.
I made a little list :wub:

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 !
1

User is offline   Kyanos 

#4

seconded.

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

0

User is offline   Helixhorned 

  • EDuke32 Developer

#5

View PostMuelsa, on 29 December 2013 - 07:29 AM, said:

aspect ratio of voxel are not the same if cstat is 0 or 16, seems correct only when the voxel are wall aligned

As a bit background, from r1908:

r1908 said:

* Voxel tweaks: horizontally scale wall-aligned ones by 5/4, make them ignore per-tile yoffset in classic (i.e. emulate Polymost; I think this is more sensible since they're not clipped to floors/ceilings anyway), make Polymost know the voxel scale

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

Flip x or y (ctat 4 and 8) dont works

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

structure members roll and pitch dont works

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.
0

User is offline   Hendricks266 

  • Weaponized Autism

  #6

View PostHelixhorned, on 10 January 2014 - 01:11 PM, said:

That's another story: arbitrary rotations around an axis that's not perpendicular to the ground are an exclusive domain of the GL renderers.

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.
1

User is offline   ReaperMan 

#7

@ Helixhorned

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.
0

User is offline   Micky C 

  • Honored Donor

#8

I can definitely think of a mod or two that could use it Posted ImagePosted Image
0

User is offline   Muelsa 

  • Bad Mother Fucker

#9

Voxels can now flip x and y with this !

mdsprite.c

Spoiler

1

User is offline   Kyanos 

#10

View PostMuelsa, on 28 January 2014 - 08:13 AM, said:

Voxels can now flip x and y with this !

mdsprite.c

Spoiler


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?
0

User is offline   Muelsa 

  • Bad Mother Fucker

#11

View PostDrek, on 28 January 2014 - 08:52 AM, said:

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?


I dont now... i hope :(
0

User is offline   Helixhorned 

  • EDuke32 Developer

#12

View PostMuelsa, on 28 January 2014 - 08:13 AM, said:

Voxels can now flip x and y with this !

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.
0

User is offline   LeoD 

  • Duke4.net topic/3513

#13

While you guys are dealing with the voxel code anyway, I'd like to ask for looking into the feasibility of implementing the missing maphack tokens (like pitch, roll, md[x|y|z]off) for voxels. :(
0

User is offline   Muelsa 

  • Bad Mother Fucker

#14

View PostHelixhorned, on 28 January 2014 - 11:36 AM, said:

- 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

:D will try

View PostHelixhorned, on 28 January 2014 - 11:36 AM, said:

- 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.

Not sure i am understanding this... need to add a z offset value ? and is this realy a good things ?

View PostHelixhorned, on 28 January 2014 - 11:36 AM, said:

- 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).

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...

View PostLeoD, on 28 January 2014 - 12:32 PM, said:

While you guys are dealing with the voxel code anyway, I'd like to ask for looking into the feasibility of implementing the missing maphack tokens (like pitch, roll, md[x|y|z]off) for voxels. :(

I think there is no reason to believe it can't be done !
0

User is offline   Hendricks266 

  • Weaponized Autism

  #15

View PostMuelsa, on 28 January 2014 - 10:23 PM, said:

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...

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.
0

User is offline   Muelsa 

  • Bad Mother Fucker

#16

View PostHendricks266, on 28 January 2014 - 10:44 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.


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

0

User is offline   Helixhorned 

  • EDuke32 Developer

#17

View PostMuelsa, on 28 January 2014 - 11:17 PM, said:

So MAXSPRITEONSCREEN is (...) maximum sprites the engine can draw in the same time..

Yes.

Quote

even if they are not in the player's field of vision...

No, on-screen sprites outside the FOV or behind the camera are culled relatively early.

Quote

Maybe is better.. culling back face still enabled, and works even with flipped shapes...

Yup, that's what I was driving at. That leaves the z offset. Here's what I mean:
Attached Image: voxel_y_offset.png
0

User is offline   Helixhorned 

  • EDuke32 Developer

#18

View PostHelixhorned, on 29 January 2014 - 09:54 AM, said:

No, on-screen sprites outside the FOV or behind the camera are culled relatively early.

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.
0

Share this topic:


Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic


All copyrights and trademarks not owned by Voidpoint, LLC are the sole property of their respective owners. Play Ion Fury! ;) © Voidpoint, LLC

Enter your sign in name and password


Sign in options