question about models, life, the universe and everything.

[KaiserJ]

is there any difference or advantage to creating a model as one single part rather than many pieces?

as an example... say you make a tank; and the tank has a vent on it. does it make any difference as to whether or not the vent is attatched (extruded directly from the model of the tank body) or plonked on top (added as part of geometry; but without welds etc)

does this affect animation? does it take more juice to render?

im pretty sure it doesnt (that a piece added as a child in the hierarchy moves according to the parent piece unless it recieves its own instructions) but i'd like to be double-sure before i move ahead with what im working on.

in before 42.

[Pxtl]

Z-fighting can be an issue. There are minor performance concerns involving wasted draw-area (part of a polygon that will never, ever, ever be seen is hidden by your graft). Dunno what else.

[KaiserJ]

z-fighting... to be clear... its when you have two polygons sharing the same space, and it sort of flashes and scratches across the surface so that you can sort of see both polys?

hmmm. didnt even consider that.

basically as an experiment im working on a shit-ton of vehicle parts, im going to texture them all on the same uvw map, and then subsequently play with the legos i've made. units, created en masse, with the lego lammas technique.

an experiment to see if i can quintuple my productivity.

[Pxtl]

Yes, z-fighting is when you have two overlapping polygons that are close in z-order (not necessarily coincident, either). This is probably less of an issue now that we've got 32-bit depth-buffers, but it was quite visible in a 16-bit one.

Really, in the modern day and age, it's probably pointless to worry about. But I'm probably not the one whose advice you should be listening to.

[jK]

This is probably less of an issue now that we've got 32-bit depth-buffers, but it was quite visible in a 16-bit one.

You mean 24bit depth + 8bit stencil ^^

[FLOZi]

There will also be errors in self shadowing if the piece isn't properly attached, and of course wasted texture space.

Also note that a single hierarchy piece can have multiple meshes (as in your 'plonked on top'), which is preferable to having each mesh be its own piece if that piece is not going to be animated.

[KaiserJ]

thankyou flozi, that puts my mind at ease. (about adding pieces to the heirarchy)

could you give examples, if its not too much trouble, of correctly and incorrectly attatching a part? (as per the shadowing error)

is it something i would do in max; or later in upspring?

[FLOZi]

You'd do it in max. It's something I ran into with S44's german HQ. I'll try and rustle up some screens.

[FLOZi]

Here we go. HQ on the left has properly 'seated' self shadows, the geometry of the greebles on the roof are 'cut in' to the roof itself. The old one whereby the greebles are seperate geometry 'plonked on' has self shadows which 'float' with camera angle and are clearly wrong.

[Argh]

Also note that a single hierarchy piece can have multiple meshes (as in your 'plonked on top'), which is preferable to having each mesh be its own piece if that piece is not going to be animated.

That. Keep the number of actual, named Pieces as low as you can (obviously be pragmatic about that).

Oh, and one last thing (FLOZi might find this useful, too): big surfaces should be tesselated to a resolution of < 0.5 square per Footprint, for best results with Spring's shadowmap system. IOW, eat triangles on big flat things like buildings, it's the only way to keep Spring from borking them, in terms of self-shading. I really like that example with that building, btw, I think we should probably sticky something like that until the future day when the shadowmaps finally work right.

[KaiserJ]

aha!

so there is a cut put into the roof there? (meaning if you removed the greebles at the top, you would see a hole?)

hmmm :/ i wonder if what i'm working on is going to work out...



these were some of the parts i had modelled, was planning on adding more (wheels and suchforth, as well as more cannons and hull parts)

and then combining them all together... although now i'm pretty skeptical as to whether this will work or not given your example image.

so... the shadows occur strangely when an unattatched model part is placed atop another? and i would have to cut holes where i wanted to have them overlap?

hmm. i could have sworn that bobs models in blood and steel were put together the way i was going to do these...

but im still confused; how does what you did in the first example image (the one with the borky shadows) differ from... say... an arm flash, with a turret on the top? ive never seen a shadowing issue there; so i think im misunderstanding

[Argh]

On small things... you won't have most of these problems. Issues with "float" get worse and worse, the bigger things get, unless you tessellate them with higher detail.

IOW, if these are normal-sized Unit parts, it will be just fine.

[FLOZi]

That. Keep the number of actual, named Pieces as low as you can (obviously be pragmatic about that).

Yep, that's what I meant.

Oh, and one last thing (FLOZi might find this useful, too): big surfaces should be tesselated to a resolution of < 1 square per Footprint, for best results with Spring's shadowmap system. IOW, eat triangles on big flat things like buildings, it's the only way to keep Spring from borking them, in terms of self-shading.

Can't say I've ever seen that.

I really like that example with that building, btw, I think we should probably sticky something like that until the future day when the shadowmaps finally work right.

I'm not sure if its an issue with Spring's shadow code or a wider issue.

aha!

so there is a cut put into the roof there? (meaning if you removed the greebles at the top, you would see a hole?)

Yes.

hmmm :/ i wonder if what i'm working on is going to work out...


these were some of the parts i had modelled, was planning on adding more (wheels and suchforth, as well as more cannons and hull parts)

and then combining them all together... although now i'm pretty skeptical as to whether this will work or not given your example image.

so... the shadows occur strangely when an unattatched model part is placed atop another? and i would have to cut holes where i wanted to have them overlap?

hmm. i could have sworn that bobs models in blood and steel were put together the way i was going to do these...

but im still confused; how does what you did in the first example image (the one with the borky shadows) differ from... say... an arm flash, with a turret on the top? ive never seen a shadowing issue there; so i think im misunderstanding

There's nothing you can do vis a vis turrets on top of bodies, by their nature they will rotate so they can't be 'cut into' the top of the tank. There are still issues, but not as pronounced. Possibly because they are separate pieces. (Which I guess undermines the principle to always minimise the number of pieces in your hierarchy But let's say that non-moving meshes should be cut-in to their parent, and moving meshes should be their own piece in the hierarchy. Of course there are exceptions when it would be wasteful to do it for no visible difference - it's your own judgement as a modeller). And as Argh said, size is an issue here. Your parts look fine.

[jK]

That's a problem with the current way shadows are handled. It's easy to fix with my custom unit shader gadget.

(Atm the shadowmap texcoords are calculated in the vertex shader, but spring uses a non-linear shadow-matrix, so with quite large triangles the interpolation (interpolation = linear) fails. The solution is to compute the shadowmap texcoords in the pixel shader instead of the vertex shader.)

[FLOZi]

Cool beans. Any chance of an engine fix?

[jK]

Cool beans. Any chance of an engine fix?

Too lazy to fix the ARB shader, but it would be part of a model renderer rewrite.

[KaiserJ]

yeah; the parts will be pretty tiny... the largest part, the biggish blue one near the bottom middle will be about the size of a flash with the tracks and turret removed.

about the tesselation... i need a bit more clarity i think; is this to do with how the shadow map applies onto large polygons and makes mistakes, and this is why you suggest *more* tesselation (meaning to split the polygons, as to break up the larger surfaces and allow the shadowmap a greater chance of applying properly?)

also custom gadgetry sounds nice should i worry about problems with this method less than i currently am?

either way thanks for the interest and the help... im hoping this method of creating units works out; it seems like i'll save a ton of time and still be able to make some pretty cool stuff.

*edit* also please forgive my ignorance and possibly foolish questions. im much more used to making tanks with pens and paint rather than on my computer... stuff that may be obvious to you guys goes right over my head for the most part

[FLOZi]

Could the custom unitshader gadget with a fixed shadow renderer be put into base files?

(Obviously it's not required to be there, but hmm, well I can't quite formulate my argument )

[Argh]

about the tesselation... i need a bit more clarity i think; is this to do with how the shadow map applies onto large polygons and makes mistakes, and this is why you suggest *more* tesselation (meaning to split the polygons, as to break up the larger surfaces and allow the shadowmap a greater chance of applying properly?)

jK's saying that's about to become irrelevant, he figured out what the real problem was. Don't worry about it.

[smoth]

but it would be part of a model renderer rewrite.

how long would something like this take?