Drawing Order

[Argh]

I've done some experiments, and it appears that the order in which Units in POV are drawn is not the reverse order of their distance from the POV (i.e., furthest away first). Basically, I found that with transparent objects, they're causing a lose situation and stencil just erases Unit geometry behind them where they intersect with nearer objects. After doing some reading, this is apparently due to not performing the z-ordering of the scene properly. I'm not quite sure how it's ordering things yet, haven't read the source.

I can (maybe) fix this, for the purpose of utilizing advanced shaders via Lua, by doing a z-ordering step before submitting the resulting display lists, but that's obviously going to run veeeeeery slowly in Lua, and I'm not even sure it can be done with UnitRendering. It would be best to fix this at the engine level.

So... I can prove that this is occuring, and I am now fairly certain that it's because of the drawing order.

This should get fixed, it borks a lot of very basic rendering stuff. It explains a lot about why certain things have been rather hard to make work- I've done some fixes on the GLSL / OpenGL settings of the Unit shader Gadget, and it will only rarely do something erroneous now, but this situation is being caused at the engine level.

Anyhow, I'll see about coding a quick z-order sort in Lua, see how that goes. If that fixes the problem, then that's pretty straightforward.

[AF]

One other hacky solution is to draw everything twice

[Argh]

No, because if I draw everything twice in the same order, the stencil will still cause transparent objects to cull fragments I don't want culled, lol.

I figured out that this was happening by accident, while setting up the transparency stuff. Some objects show right through my "domes", and you can view them on the other side, as you'd expect. Some are magically erased. I've tried it with various things, and it doesn't matter if they're using the GLSL shader or not, so it's not something borked on my end per se, it's just OpenGL doing what it's supposed to do, when you draw one object after another one and it's behind the first object- it gets culled.

IDK whether it's just operating in order of UnitIDs or what, but basically that's the issue, and it's obviously something fairly arbitrary- I can have two objects on the other side of a dome, built in order and both using the shader, and one gets erased and the other one doesn't.

[lurker]

Everyone kind of knows this already. It takes expensive cpu sorting to have such translucency. Unless you actually mean transparency and something is broken? Your posts aren't very clear.

[Argh]

First off, I obviously meant "translucency". I keep forgetting that "transparent" means something else, technically. My apologies.

Anyhow... why's it so expensive?

It's just getting the visible unitIDs, the distance between them and POV, and doing a quicksort based on the distance. Is quicksort just that slow, or is there another serious catch involved?

I know that there are a lot of sqrt's involved, but this is something where you don't even need much precision, so maybe there are shortcuts. Perhaps just the rough estimation method would be fine for 99% of the cases.

[lurker]

Between units? You have to calculate and sort each triangle to have proper translucency.

[jK]

@ARGH

DID YOU EVER READ WHAT PPL SAY YOU!?
This was told you already soo many times.


Please, can someone just close this, it isn't funny anymore.

[Argh]

You have to calculate and sort each triangle to have proper translucency.

Ok, perhaps we're wandering off course here. I'm not talking internally in a Unit's geometry- I've solved that problem as well as it probably can be solved without doing a full sort.

I just need Units that are farther away drawn before Units that are drawn nearer to the POV. That's all.

And jK, if you would actually view the screenshots of what I already have working in Games / Mods before screaming at me, we might have a slightly less grouchy conversation. I understand that you thought I was asking for the impossible again. I'm not. I get it- depth-sorting the triangles every pass is not possible. But plenty of engines do what I'm asking for, which is to render objects in strict order of distance, and Spring apparently doesn't, and nobody noticed until I got this working.

I'm asking for something reasonable that should solve several problems, is all. Rendering the unitIDs in the order of distance- farthest away first- allows my shader to operate reliably, and other things like it to operate without bugs.

Here, if you're too lazy to check G&M:

I solved the z-order issues internal to Unit geometry, obviously.

[FLOZi]

Presumably your per-unit translucency works along these lines ?

http://www.codesampler.com/oglsrc/oglsr ... ansparency

[lurker]

I think it goes by unitdef now to lower the number of texture binding times, but that shouldn't have too much of an impact on performance. Is changing the order of unit renders enough, or would it take more? And your first post is hard to read and overly blameful, work on being more concise and clear.

[Argh]

Is changing the order of unit renders enough, or would it take more?

That will solve the problem entirely.

your first post is hard to read and overly blameful, work on being more concise and clear.

I apologize if it seemed like I was attacking anybody. It wasn't meant that way, I just realized that I'd hit a fundamental stumbling block, is all, and it was aggravating me, and as usual I seem to have mangled technical terms.

Presumably your per-unit translucency works along these lines ?

No, it's actually a classic sorted translucency approach. I'll explain how to make it work when I release the next version of the shader, I promise. It doesn't require sorting triangles in the display lists, though- it draws in a very strict order and is very easy to set up.

[jK]

You have to calculate and sort each triangle to have proper translucency.

Ok, perhaps we're wandering off course here. I'm not talking internally in a Unit's geometry- I've solved that problem as well as it probably can be solved without doing a full sort.

I just need Units that are farther away drawn before Units that are drawn nearer to the POV. That's all.

And jK, if you would actually view the screenshots of what I already have working in Games / Mods before screaming at me, we might have a slightly less grouchy conversation. I understand that you thought I was asking for the impossible again. I'm not. I get it- depth-sorting the triangles every pass is not possible. But plenty of engines do what I'm asking for, which is to render objects in strict order of distance, and Spring apparently doesn't, and nobody noticed until I got this working.

You did nothing, you just played again just with a shader a program done for you.
Also calling transparency "very basic rendering stuff" is just blasphemy.
And it would need a "fix" is just wrong, you want a feature request!
Then you don't even have any knowledge how stuff gets done and say it would be easy to add. And when ppl with more knowledge explain it to you, you just ignore them and repeat the same dumb stuff a month later!

[lurker]

You weren't attacking anybody, you were attacking and blaming spring.

[KDR_11k]

AFAIK professional engines don't bother with sorting either. No translucency has the advantage of needing only the depth buffer. An optimization is to sort only translucent surfaces.

[Argh]

1. What I'm doing is working, and I do know what I'm doing (this time).

2. The change I am asking for will work.

Screen proof:



You can see that two pickup truck models, both using the GLSL shader, are being drawn there. One is being stenciled out of existence, one is not, and it's due to the drawing order of the Units- that's all.

IOW, it works just like I said, I just need a simple, low-impact change that will work like I am saying it will, that's all.

There's nothing wrong with my GLSL or the OpenGL that sets it up- one object's fragments are losing a depth test, the other is not because it's already been drawn. It's really that simple.

Oh... and I have done not one, but two layers of translucence on that test object. I guess I need to point this out really bluntly- this time, I actually know what I'm talking about. So, can I get this fixed by somebody now? Please? I don't mind it when I'm told that XYZ is impossible, but this is a pretty clear demonstration that I got around those limitations. I'm fairly amused that nobody has stumbled on my method, to be perfectly honest, but I'll show you my source code and a test object if that's what it takes. But I'm still trying to see if there's a tricky hack that I can use to re-enable parallax without hitting the 32-float problem, so I'd rather keep it to myself for a few more days.

[AF]

Argh the point being that this sorting your asking for is not trivial

Changing unit rendering orders would fix this. But this si not as easy or as lightweight as you think.

Try and think how you would devise how to order the units for a moment. How do you deal with tiny units next to big buildings where the bigger unti is both further away and nearer at its extremities?

[Argh]

Try and think how you would devise how to order the units for a moment. How do you deal with tiny units next to big buildings where the bigger unti is both further away and nearer at its extremities?

Well, there you'll see a bork. But if the tiny unit's the one that's translucent, you'll practically never see the bork, except down at screenshot level.

A better question would have been, "what happens, if you make a big transparent dome that multiple Units can drive under, where some are closer to the POV than the center of the dome"?

The answer is, "that will always bork, given the proposed method". IOW, some things simply aren't possible, with such a simplistic sorting method.

But it's possible to fix that, for the vast majority of cases. Sorting both based on distance and a unitDef tag specifying that they're translucent, so that translucent objects draw last, but in order of their distance from the POV, should cut borks to a minimum (but again, not preventing them entirely).

IOW... I don't have a method that will always prevent a bork, short of completely sorting all the triangles, and treating the Unit geometry as one large display list. Since that's too expensive, I'm perfectly willing to accept some possibility of a bork, because it'll be pretty rare, given the typical use cases.

Note: my method does NOT bork with transparent objects. They're fine, and there aren't any problems with culling there. That part took a long time to figure out this weekend.

[KDR_11k]

Generally translucent surfaces are rendered last but not sorted. Just make sure you draw yours after everything else is drawn.

[Argh]

Generally translucent surfaces are rendered last but not sorted. Just make sure you draw yours after everything else is drawn.

Then they'll just draw through mountains, etc., and what if you have transparent stuff on the underside of something? lol.

[momfreeek]

Generally translucent surfaces are rendered last but not sorted. Just make sure you draw yours after everything else is drawn.

Then they'll just draw through mountains, etc., and what if you have transparent stuff on the underside of something? lol.

If those issues *never* crop up with a random draw order, how is sorting the draw order going to introduce them?

to be more specific:

The pixel z-buffer already takes care of those cases. The *only* problem cases are translucent models being drawn before other models.. so draw them last.