PMF model format

[melchips]

The current model format (PMF) doesn't seem appropriate for the OpenGL renderer.

As a matter of fact, I don't see any obvious way of avoiding the z-fighting issues as nothing, in the format, prevents two polygons to share the same space.

Moreover, I can't apply smooth lighting as I did on the map.

Possible solutions

1. improve PMF format
   • prevent two cubes to share the same space (maybe an octree-like structure could solve this ?)
2. do boolean operations on cubes to remove shared faces (are you seriously considering it ?)
3. add another format
   • like kv6 support ?

In my opinion, models should be created just as maps (placing/removing blocks while flying around the model like in the game, just like the current map editor). That way, it would be a standard and easy interface. We would need to handle a few things like the size of a block (to increase the model resolution, divide the size of the blocks by two), and the center of the model (to place it correctly in the game world).

What do yo think about this issue ? Have you got any other idea ? Am I missing something ?

Is models texturing out of the discussion because it can't be supported on both renderers ?

Side note

If I alter the following line in gl/render.c, the rifle hasn't any z-fighting issue on my box anymore as no faces are sharing the same space (but the others models aren't rendered properly because of the newly invalid radius value) :

render_pmf_cube(bone,
    pt->x/256.0f, pt->y/256.0f,
    pt->z/256.0f,
    pt->r,
    pt->g,
    pt->b,
    pt->radius*2.0f/256.0f);

to

render_pmf_cube(bone,
    pt->x/256.0f,
    pt->y/256.0f,
    pt->z/256.0f,
    pt->r,
    pt->g,
    pt->b,
    pt->radius*1.0f/256.0f);

[Ericson2314]

I support implement KV6

[melchips]

KV6 is nice and already has the pivot coordinates in the structure. However, to my knowledge there is no bone information nor scale information. Should we make a new format based on KV6 ? If such a format is added, is there a need to keep the PMF support in the engine ?

[Ericson2314]

how does kwalk in Voxlap do animation then?

[melchips]

Thanks for pointing kwalk to me.

Reading the doc, it seems that :

• limbs must not be drawn next to each other in the kv6 file
• after loading the kv6 file, limbs are meant to be connected manually inside the kwalk app
• I think data is then stored in the kva file

So, we somehow have to make the link between multiple kv6 files (one kv6 per bone maybe ?).

I may understand this wrongly, feel free to enlighten me.

[Ericson2314]

Yeah, though I've been porting voxlap a while I know little about it's algorithms. It does seem likely that kva would have something to do with it. If Ace of Spades uses kva too then I think kv6+kva is definitely the way to go with iceball.

(I accidentally hit close)

[iamgreaser]

Replacing the PMF format with KV6 is not the way to go.

What we should be doing instead is generating, say, a kd-tree inside the GL renderer, and rendering it like that.

[iamgreaser]

Z-fighting issues fixed by giving the cubes a slight sine-based offset. If you don't like the method I used, consider sorting the cube faces by planes and using the painters' method. There are MANY ways to solve this problem, I just used what I thought was the simplest, and it actually looks OK.

If you think this method sucks, you can reopen this issue.