Supermodel Forum

Ah very interesting! I suppose the Model 3's rasterizer was able to make these corrections automatically when splitting up quads. I guess we'll have to use the full texture coordinate space to fix the issue then?

But what about non-planar quads? Were they textured as if they were a planar quad?

I'd like to think that the same principle can be also extended to normals. That will change the way the polygons are shaded in fixed shading, sun shading, and specular shading.

Looking at some of the screenshots harry provided I'd say it's quite possible the model3 is directly drawing quads, and not splitting them up as triangles. Emulating this on modern hardware is pretty damn difficult. Even if we can correct the texture coordinates doing per vertex lighting the same way as the hardware is close to impossible :/

Luckily most of the quads draw fine, even the non planar ones.

Ian wrote:Looking at some of the screenshots harry provided I'd say it's quite possible the model3 is directly drawing quads, and not splitting them up as triangles. Emulating this on modern hardware is pretty damn difficult. Even if we can correct the texture coordinates doing per vertex lighting the same way as the hardware is close to impossible :/

Luckily most of the quads draw fine, even the non planar ones.

It may be an issue that just has to be documented with some examples and explanations of what is observed/what has been tried so that it can be revisited in the future. I'm a big fan of large technical descriptions in at the top of files (as you can see in Render2D.cpp and Legacy3D.cpp ) even though they sometimes run the risk of becoming stale and confusing.

Does this also apply to Dural's model? I will make a save state for you guys to see it because Dural had such metallic polygons like any other cars in Scud Race.

Found this quite interesting ..

https://www.youtube.com/watch?v=brC96Rtmp2Y

That's pretty much exactly some of the bugs we are seeing.

That's an interesting illustration of the problem!

I think the only solution to this problem is Harry's suggestion of using geometry shaders. Unfortunately that means we'll have to convert the project to opengl 3+. Might make sense to do this at some later date.

Well .....
I had a brief touch upon this problem before trying out some nvidia code to render quads. But there were 2 problems,
1) the code was crazy complicated handling all kinds of bow tie and other mad polygons
2) it totally blew apart if i duplicated the last vertex making a triangle, which would mean triangles would need a totally separate render path which would seriously suck

Anyway I tried again with the example code in the super bible

This is what a regular triangle looks like with regular interpolation

Pretty bog standard

Anyway this is a triangle rendered with quadratic interpolation with the last vertex being simply repeated

Really quite different. I think i actually prefer the look of the quad version.

This is a quad rendered with regular interpolation (what we are currently doing)


And the same but with quadratic interpolation (what readl3d) is doing


Pretty exciting. I think we can really add these to the shaders with minimal pain really. The code is simple. My best guess based upon non experimentation is, that real3d basically only rendering quads. And that triangles probably shared the same render path. It wouldn't make sense to add a totally separate render path for triangles with their own interpolation code. Most games seem to predominately use quads.