Supermodel Forum

Sega Rally 2 shadows.

Arcade PCB:


Supermodel:


In Model3 also, the windscreen seems "discarded" by the snow & dust streams when they overlap. Surely due to the mentioned depth test, but probably also by the different rendering priority

HarryTuttle wrote:I've got instead a theory about the polygon orientation: I think that the Real3D keeps dynamically their face normals toward the camera, this resolves some issues in oceanhunter (the transparent helmets in attract mode), the atmosphere halo around Endor in some open space scene in SWT, etc. Maybe that could be how "shadow-polys" are rendered without flicker, instead of implementing a co-planar check every time.

I don't understand what you mean here. Let's say I have two triangles: one transparent and one non-transparent, side by side, with the polygon normal of each pointing toward the camera. Both are visible because we are looking at their front face. Now as we move the camera around them (e.g., walk behind them), what are you suggesting would happen?

If we view them from the backside, the normals will point away from the camera and they should be culled away, right?

When you say "Real3D keeps dynamically their face normals toward the camera", isn't that the same as having a double-sided polygon (the face normal/backface culling are ignored entirely)?

I'm also sure that transparent-not-textured poly are rendered in another, separate, pass in the render pipeline. Last year I've made a proof-of-concept patch on the old engine and it fixed, for example, the priority (visibility) between the snow and the shadows in Sega Rally 2, maybe there're other cases.

Interesting. So you are saying that textured polygons are rendered in one pass (both transparent and non-transparent ones) but that non-textured transparent polygons are rendered separately? Or only non-textured polygons with this "shadow" or "layered" bit set?

The transparency error on the helmets in ocean hunter is because the polygons need to be depth sorted. I don't think the hardware did this. It's a pretty common error on most systems, new or old. It's made worse on the model3 because it always depth tests translucent polygons, so sometimes the back faces are never drawn because they are depth tested out.

Bart wrote:I don't understand what you mean here. Let's say I have two triangles: one transparent and one non-transparent, side by side, with the polygon normal of each pointing toward the camera. Both are visible because we are looking at their front face. Now as we move the camera around them (e.g., walk behind them), what are you suggesting would happen?

If we view them from the backside, the normals will point away from the camera and they should be culled away, right?

Sorry but, as you can see, English is not my native language.

Anyway, I mean what you said but with an exception: with opaque polys the double-sided bit is respected, while IMHO is ignored for transparent/translucent ones and set to be always sigle-sided. But when, in your example, we view them from the backside the hardware will flip the normals and will not be culled.

In the case of ECA colored balloons (yes, they're my obsession ), we should normally see the outer side and the inner side 'cause of translucency and double side, instead from the footage analyzed, it seems that that there's always only one side shown.

Same goes for the scuba helmet in Ocean Hunter. If you hack <New3D.cpp> and force single sided for everything transparent you will "fix" most of the issues, but introduce new bugs to, for example, SWT in particular the polygon with the explosion animated texture in the open space battle scenes. They would flicker 'cause they flip continuously the normals during the animation sequence.

If you can find some clear quality footage of ocean hunter and the helmets, it might help

Bart wrote:Interesting. So you are saying that textured polygons are rendered in one pass (both transparent and non-transparent ones) but that non-textured transparent polygons are rendered separately? Or only non-textured polygons with this "shadow" or "layered" bit set?

I think of a rendering pipeline more or less like this one:

Code: Select all

// Let's assume a "RenderScene" function like this one:
// RenderScene (int priority, bool alpha, bool textured, bool tex_alpha, bool poly_alpha)

RenderScene (pri, false, false, false, false); // opaque/base textures
RenderScene (pri, true, false, false, true); // i.e. Sega Rally 2 shadows
RenderScene (pri, true, true, true, false); // i.e. Sega Rally 2 headlights
RenderScene (pri, true, true, true, true); // i.e. Sega Rally 2 dirt/snow
RenderScene (pri, true, true, false, true); // i.e. Sega Rally 2 car glasses


It's more similar to what appears in Model3 (artifacts included).

HarryTuttle wrote:Anyway, I mean what you said but with an exception: with opaque polys the double-sided bit is respected, while IMHO is ignored for transparent/translucent ones and set to be always sigle-sided. But when, in your example, we view them from the backside the hardware will flip the normals and will not be culled.

In the case of ECA colored balloons (yes, they're my obsession ), we should normally see the outer side and the inner side 'cause of translucency and double side, instead from the footage analyzed, it seems that that there's always only one side shown.

Sorry, I'm a bit slow. I still don't see what you mean -- when is the normal flipped, in your opinion? The normal being flipped is the same as the polygon being double-sided, right? In the case of translucent double-sided polygons, I think you mean that the normal is *not* flipped and therefore the polygon is discarded. For opaque double-sided polygons viewed from the back, the normal *is* flipped and the polygon is no longer discarded. Is that what you mean?

To put it another way: if the normal is flipped for the double-sided translucent polygon in my example, it will *not* be discarded. So the normal must not be flipped in order for backface culling to remove it.

See if you can fix this one ..

(my engine)


(Bart's)


See the window at the back. Bart's traverses everything backwards .. which in this game looks correct.

Probably should add .. looks like the right hand side of cropped off the speed display at the bottom. Wonder if that's intentional.

Ian wrote:See if you can fix this one ..

No, wait... I've got the fixed one... but with your engine. What's happening here?

(O.T. I'd like to post a picture but it says "Sorry, the board attachment quota has been reached.", if I delete my past attachment from control panel will the one already posted disappear too ?)

Just upload images to imgur.com or similar