Multipass rendering with nextgen renderer!

It would be cool if the nextgen renderer will support multipass rendering with multiple textures per object. Texture types should include regular diffuse maps, specular maps, reflection maps, and what not, all with alpha channels.

Thanks for considering.

Hey Renault... yeah, more taking advantage of video cards... I don't know what's in store but at least for now, I've thought a multipass renderer (even offline through caching of data or something) for Snapshots taken would be a great idea, i.e. the saved-to-disk photo looks a lot better quality and higher rez than actual inworld footage because it was postprocessed.

Id be happy if they just fixed the alpha texture anomolies. I really dont like the artifacts that happen when two alpha textures overlap.
==Chris

Oh hey Chris! Hope you had a good sleep

Yeah... I don't like hair attachment texture glitches... and how transparencies used for prim-shoe heels display quirkily too. This may be a desired thing once in a so-called blue moon, but for the most part, it's frustrating.

Well, I want multitexturing mainly to create shiny clothes without texture hacks (painting random white stuff as "reflections" / shinyness), and that adapt to the local lighting. It would also help doing all sorts of fabrics via the specular map, like satin and all that.

Christopher, alpha sorting isn't fixable. Neither is Z-flashing. Every graphics engine on earth will have those problems... the way most games deal with it is on the content level... by making sure you never have a bunch of overlapping alphas.

Eggy, with all due respect, I just can't believe alpha sorting isn't doable. Check out this OpenGL tutorial from 1999:

http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=08

A short quote:

"The correct way is to draw all the transparent (with alpha < 1.0) polys after you have drawn the entire scene, and to draw them in reverse depth order (farthest first). This is due to the fact that blending two polygons (1 and 2) in different order gives different results, i.e. (assuming poly 1 is nearest to the viewer, the correct way would be to draw poly 2 first and then poly 1. If you look at it, like in reality, all the light comming from behind these two polys (which are transparent) has to pass poly 2 first and then poly 1 before it reaches the eye of the viewer. You should SORT THE TRANSPARENT POLYGONS BY DEPTH and draw them AFTER THE ENTIRE SCENE HAS BEEN DRAWN, with the DEPTH BUFFER ENABLED, or you will get incorrect results. I know this sometimes is a pain, but this is the correct way to do it. "

the way SL optimized it's alpha sort was to treat each texture face as a single item instead of each polygon. This results in hollow shapes to be miss sorted and many of the strange effects we see.

To get alpha sorting to look correct you need to treat every polygon as a single entity and then do collision detection on your polygons so you get clean breaks on overlaps (this is so those tacky prim trees would render properly, if this was done they wouldn't look so tacky).

It would also make prim water take less prims among other things. Yay for prim lakes. :>

On another note, say it right! (See attached picture)

They should just switch over to ray-tracing for all the rendering. Not only will this fix the Z-flashing and alpha sorting issues, it will also allow realistic shadows, reflections, and refraction.

Er. Maybe it's morning, and I missed any sort of sarcasm and/or rendering knowledge, but...

Isn't ray-tracing breathtakingly slow? IT's for photorealistic single images or rendered movies, yah?

SL is slow enough

Yes, raytracing is slow - here's an interesting site - Quake with a raytracing engine.

Take alook at what it takes to get 20fps.... Oh, if only I could afford that!

well in fariness, that engine happen to be doing allot more then just raytracing. And it was only written in 6 months. It's using displacement mapping, real time shadows, and a bunch of other thing but I can't rember their name.

Well, lets just get LL to integrate PRman then, ideally with Blue Moon for frankenrendering reflections and refractions. And it'd be faster than a full raytracer!

wow!

Actually, raytracing is only slower for simple scenes. Depending on the specific implementation details, somewhere around 20,000,000 triangles or so, raytracing starts being faster than scanline rendering, and as the scene gets more complex, the advantage of using raytracing grows. Further, raytracing is embarassingly parallelizable -- it's one of the few situations where adding a second processor to the job will cut the run time in half.

LOL. Screw PRman. I want Mental Ray with Lume Tools!

Brazil r/s owns Mental Ray. Seriously!