Real3d transparency

Technical discussion for those interested in Supermodel development and Model 3 reverse engineering. Prospective contributors welcome.
Forum rules
Keep it classy!

  • No ROM requests or links.
  • Do not ask to be a play tester.
  • Do not ask about release dates.
  • No drama!

Real3d transparency

Postby Ian » Thu May 24, 2018 4:18 pm

Something I've been battling with for a little while now, is how the real 3d is handling transparency. Most of my previous efforts had failed.

From an end user point of view, the real3d seems to be doing some pretty impossible things. First thing is textures with transparency

Image

With a traditional renderer, the only way to render this correctly is to sort it back to front and then draw it.

Previous efforts without sorting looked like this

Image

Lemans24 was also stuffed with these kinds of errors. Originally I assumed that the hardware was doing some kind of sorting. But I realised with lemans24, especially on the trees that this was not possible

Although the black halo is not so noticably, on a blue or whiteish background the halos around the leaves really stand out

Image

This is what the alpha polys look like

Image

They are intersecting .. how can you sort this to draw correctly? The answer is you can't it's impossible without splitting the polys. So how can the hardware be drawing these polys correctly? The only answer I think is it's drawing the opaque parts first. Then drawing the transparent parts in a second pass. If you assume that suddenly all these transparency errors go completely. No more halos around the trees.

Image

The 2nd puzzling thing is, why is there no z fighting on shadows for alpha polys? This is what supermodel looked like before I implemented the stencil buffer ..

Image

A depth pass won't fix this, since co-planar polys will still draw and blend over the top of each other. The only? way to fix this would be to use the stencil buffer and prevent overlapping writes ...

But doing a stencil only pass to prevent overlapping polys, you get these kinds of crazy errrors.

Image

And the actual h/w
Image

The balloons render correctly. Okay so the hardware must be doing a depth / stencil pass.

But doing a depth / stencil pass you get these kinds of anomolies when compared to the real h/w.

Image

The shadow and the overlay are different priority layers. The depth buffer is wiped between each layer so how can you do a depth / stencil pass? The answer is you can't. I'm pretty sure it's not possible. So how the hell is the h/w doing transparency? I think the answer is, the hw is actually drawing all the transparent parts to a totally separate layer or render target, and blending the final result over the top of the screen. In almost all examples the model3 only seems to have 1 layer of transparency. Overlapping transparency is almost non existent. By having a separate render target, if the depth test passes you simply overwrite the previous values, so in the case of co-planar polys, there is no overlap, no z fighting. But the beauty? of this is you don't need to do a depth pass first. But why would you need this anyway? The answer is because of node level transparency. If you either don't do a depth pass, or use this, some polys will draw twice or more times, and look totally broken.

Actually I think there are 2 transparency layers. I think the transparency select bit switches the layer.

Here you can see a rare case of actually overlapping transparency (smoke + shadow).

Image

The blending between the 2 layers is weird. If you draw the polys normally and blend over the top they don't look anything like that. It's like a weird dumb blend between the 2 layers. Add up colours between 2 layers, divide by 2. Then draw final result (at a guess).

Here is the bits
Image

The smoke is the only bit which sets the pattern select bit. I originally thought that pattern select was for stipple alpha? But I'm pretty sure it says draw to layer 2.

Just need to code a solution for this .. :)
Ian
 
Posts: 1520
Joined: Tue Feb 23, 2016 9:23 am

Re: Real3d transparency

Postby Bart » Thu May 24, 2018 9:21 pm

WHOA. Mind: blown.

That's a really fascinating idea. I've never heard of any such system before. Has such a rendering technique even been suggested in software rasterizers?
Do you think that separate frame buffers were kept for this purpose? That's a lot of memory at a time when memory was very expensive. Some of this could potentially be verified by tallying up the amount of RAM on the board.

Note that something called 3D-RAM was employed and I think it was for the frame buffer. It was a type of "active memory" -- memory that supports some set of logic and arithmetic operations, in this case related to color blending. It was specifically designed for use in 3D frame buffers, hence the name "3D-RAM". I have hardware manuals for the memory ICs used on Model 3. I can send them if you'd like to peruse them.
User avatar
Bart
Site Admin
 
Posts: 2188
Joined: Thu Sep 01, 2011 2:13 pm
Location: New York City

Re: Real3d transparency

Postby Ian » Fri May 25, 2018 2:29 am

Well the real3d is the only system that I know of that did the automatic LOD selection for models. I know other systems at the time supported writing to arbitary frame buffers. Check out the n64 -> http://gliden64.blogspot.co.uk/2013/10/ ... intro.html

You could do all kinds of crazy things with it, including using the depth buffer as a texture for fog. Quite a unique idea. But it also supported aux buffers (as they would be in ogl). It's not really that much memory, for 496x384 even at full 8 bits per pixel that's only 700k. There is plenty of unused culling memory.

Anyway back to the automatic LOD. The point is to save frame rate by fading out complex model and fading in cheaper models. But do to do a depth pass properly you would have to do full texturing (with alpha/contour texturing), which would mean 2x the work to draw these models, that's going to hurt frame rate and fill rate. So drawing alpha to a separate buffer would save a depth pass and be a lot cheaper potentially. I can only look at these things from a kind of higher level since I don't even own a model 3 board. But that is my best guess as to what is happening. I tried doing a depth only pass on transparent polys and it looks almost perfect for sega rally and ocean hunter. Only missing the weird blending between the 2 layers.
Ian
 
Posts: 1520
Joined: Tue Feb 23, 2016 9:23 am

Re: Real3d transparency

Postby Ian » Mon May 28, 2018 1:13 pm

Well for anyone that is following this thread
https://imgur.com/a/EfOU3Tk
here is a WIP screenshot. Transparency is being rendered to a separate layer from the main colour buffer. Still to separate the 2 transparent layers, then write some shader code to draw / blend them.
Ian
 
Posts: 1520
Joined: Tue Feb 23, 2016 9:23 am

Re: Real3d transparency

Postby YoYo09 » Tue May 29, 2018 2:02 am

Ian r731 bug report
la machine guns, the lost world test
all have a texture problem.
Image
Image
Image

r729 all is normal
Attachments
3.JPG
3.JPG (115.46 KiB) Viewed 1883 times
1.JPG
1.JPG (102.74 KiB) Viewed 1884 times
YoYo09
 
Posts: 66
Joined: Mon Nov 28, 2016 7:43 pm

Re: Real3d transparency

Postby Ian » Tue May 29, 2018 7:24 am

seems i broke the hash function somehow .. i'll fix it when i have some time
Ian
 
Posts: 1520
Joined: Tue Feb 23, 2016 9:23 am

Re: Real3d transparency

Postby Ian » Wed May 30, 2018 6:15 am

Well .. this is my first attempt at solving this

Image

The transparent glass on the car blends with the smoke/fire. The glass is drawn with 1 layer, and the fire/smoke another.

Without it looks like this

Image
Ian
 
Posts: 1520
Joined: Tue Feb 23, 2016 9:23 am

Re: Real3d transparency

Postby sonic32 » Wed May 30, 2018 10:23 am

Completely like the Picture on (Model 3), great work by Ian :)
User avatar
sonic32
 
Posts: 108
Joined: Tue Dec 20, 2011 11:43 am
Location: Slovakia

Re: Real3d transparency

Postby Bart » Mon Jun 18, 2018 5:04 pm

This is some really brilliant work, Ian! I would have never gotten this far in a million years :) If I recall correctly, your original motivation in rewriting the rendering engine was just to get VF3 working better? That's how it is with emulation, though: no matter how obscure the platform, once you get hooked, you can't resist the pull of achieving perfection!

I have a question: could this have been accomplished without multiple frame buffers but instead with multiple render passes if extra bits were present in the frame buffer for alpha layers? I don't know if I grasp the significance of the pattern select bit (or layer select, as you now see it). But it sounds to me like layer 2 will blend over layer 1 and the opaque layer beneath, so I guess my idea wouldn't make sense.

I'll have to look into the memory capacity on the video board. As I mentioned in my email to you, a special type of RAM chip with blending arithmetic capabilities was used to implement frame buffer memory. Maybe they used these chips to composite the separate buffers together or maybe they found some clever way of doing multi-pass rendering using the blending capabilities of these chips. Multi-pass rendering would require traversing the scene graphs multiple times and re-doing all the matrix multiplications. I'm not sure whether this or adding more memory would have been considered the costlier option back then. Memory was definitely expensive, though. Step 1.0 actually only included 2MB of RAM on the CPU side.
User avatar
Bart
Site Admin
 
Posts: 2188
Joined: Thu Sep 01, 2011 2:13 pm
Location: New York City

Re: Real3d transparency

Postby Ian » Tue Jun 19, 2018 2:00 pm

I have a question: could this have been accomplished without multiple frame buffers but instead with multiple render passes if extra bits were present in the frame buffer for alpha layers? I don't know if I grasp the significance of the pattern select bit (or layer select, as you now see it). But it sounds to me like layer 2 will blend over layer 1 and the opaque layer beneath, so I guess my idea wouldn't make sense.


It might be possible for the step 1.0 games.

But if you look at this
Image
Look at the green overlay on the left. It totally removes the shadow under it.The background is like priority 0, and the green overlay priority 1. We know the depth buffer is wiped between priority layers, otherwise you wouldn't be able to draw anything on top. So not even sure you could make that work with a multi pass solution
Ian
 
Posts: 1520
Joined: Tue Feb 23, 2016 9:23 am

Next

Return to The Dark Room

Who is online

Users browsing this forum: Majestic-12 [Bot] and 1 guest