Make Simutrans speak your language.

OpenGL rendering with semi-static geometry

Started by Ters, April 20, 2013, 10:17:11 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.


I'll need more reading of the code to get the idea, and contribute to this. I see your points.

About point 1, are your refering obj_t is not the place to add this, or that we'll need more code and change how they are processed?

About 2, I don't really understand what's the difference between a 3D geometry and 2D sprites, aren't supposed 2D sprites to have a z-value? Yes, we have to be able to mix static geometries with moving objects, and update them separately. I thought y coordinate would solve this.

Do you think adding information for makeobj is needed for any of this or would simplify something?


1. There are a couple of things, I don't remember exactly which apart from smoke, that escaped the generic thing I did to pick up most of the things that changed. I had to do some hacks to get those working.

2. The main problem with 3D geometry is that it doesn't always correspond with the real-life geometry of the objects, so pixels get a wrong z value. This caused overhead wires to be visible through the bridge above. Front images are visible through the back images on the tile in front. Vehicles disappear partially into the ground on slopes, and also come into conflict with front images, as well as the back images in front of these again.

I therefore think it's time to try out plain 2D billboarding (so more or less like my previous attempt, just divided into semi-static batches rather than fully streamed), but the trouble is coming up with good z-values that "always" work. Simutrans doesn't simply render things back to front, because that won't work well at all, nor does it get it 100 % correct the way it does it either.


Why is the z-coordinate not just the order in the drawing list? That would give the same drawing order than 2D.


Quote from: prissi on December 10, 2013, 09:57:29 PM
Why is the z-coordinate not just the order in the drawing list? That would give the same drawing order than 2D.

That's more or less the idea, but the current drawing list isn't static. The z-coordinates of ground tiles, buildings and other static stuff must have gaps for vehicles and other moving objects "to pass through". The current drawing list isn't correct either, as already mentioned.