PDA

View Full Version : raytracing vs. scanline - interesting nvidia take



jin choung
03-07-2008, 01:02 PM
http://www.pcper.com/article.php?aid=530

as it pertains to lw, it would be nice if lw was pursuing scanline rendering as a parallel development path so that we get things like micropolygon dicing for things like sub-poly displacement....

different tools for different jobs ain't a bad way to go imo.

jin

Lightwolf
03-07-2008, 01:29 PM
as it pertains to lw, it would be nice if lw was pursuing scanline rendering as a parallel development path so that we get things like micropolygon dicing for things like sub-poly displacement....

Oh but we have that already, it's called "Classic" camera. Not that it buys you sub-poly displacement automatically (and there are "raytracers" that handle sub-poly displacement as well, i.e. VRay, mental ray, modo - even though most of them are more or less hybrid renderers anyhow). Let's also not forget that this was written with gfx board in mind... where the trade-offs are a bit different compared to production renderers.

Cheers,
Mike

creativecontrol
03-07-2008, 01:49 PM
I remember someone from ILM talking about a new system of "approximating raytracing" with a method developed by Nvidia. They used it in Pirates and some others.

Apparently, raytracing can cast a lot of wasted rays in very high geometry situations where there is more polygons than pixels, such as a detailed object seen at a distance. They had this new method incorporated into Renderman and it was working well. It gave the same (or very close) results as raytracing but much faster.

Sony pictures also used it in Surf's Up. Sounds interesting.

jin choung
03-07-2008, 01:51 PM
right. i know we have a scanline renderer but it seems development on that has stopped.

it would be nice to get the benefits of scanline like subpixel displacements. and if that tech is possible is raytracing, is it fast?

and yah, the article is focused on real time applications but some of the points that he makes are principles that apply across the board.

it seems that we're pursuing ray tracing solely and i think it might be best to have a really good scanline renderer too...

so that would be... what... 3? ray trace pure. hybrid. scanline pure.

jin

jin choung
03-07-2008, 01:55 PM
I remember someone from ILM talking about a new system of "approximating raytracing" with a method developed by Nvidia. They used it in Pirates and some others.

Apparently, raytracing can cast a lot of wasted rays in very high geometry situations where there is more polygons than pixels, such as a detailed object seen at a distance. They had this new method incorporated into Renderman and it was working well. It gave the same (or very close) results as raytracing but much faster.

Sony pictures also used it in Surf's Up. Sounds interesting.

i read that article too. if i remember correctly, it was about culling out tons of displacement detail that was showing up on screen as being one pixel or smaller. they used something from GPU Gems book and figured out a way to quickly get an averaged sample for all that detail under the single pixel.

yeah, that would be a nice render optimization technique to have....

jin

jin choung
03-07-2008, 01:59 PM
personally, i like the whole "classic" prman, pixar approach.

the only thing that matters is that it looks good for what you're going for...
FAKE EVERYTHING.... everything in moviemaking is fake anyway.... "accuracy is for chumps"... approach.

it made my heart glad to hear that one of the production mandates for rattatouillie was "if at all possible, avoid ray tracing".

and all that standing in MARKED contrast to the whole "physically accurate" renderers out there that many are fans of.... yah, when you get to the point where you have a renderer that can create a rainbow diffraction from white light, that might serve some purpose somewhere but for me, that's ridiculous overkill.

jin

creativecontrol
03-07-2008, 02:13 PM
I have always like Lightwave because it offered both! But you're right, I'd like to see some work done on scanline techniques as well. Perhaps something similar to Renderman's deep shadows that give better shadow mapping.

Most movie production has avoided raytracing just because of speed. Renderman didn't even have it for the longest time. However, LW has always had one of the best "hybrids" in my opinion. Very selectable.

Perhaps Newtek could incorporate scanline techniques back into the new camera types and improve them, especially shadow mapping.

Lightwolf
03-07-2008, 02:14 PM
it would be nice to get the benefits of scanline like subpixel displacements. and if that tech is possible is raytracing, is it fast?

Is modo fast? Is mental ray fast? Yes and no, it depends ;)

and yah, the article is focused on real time applications but some of the points that he makes are principles that apply across the board.
There's one thing that shouldn't be forgotten here... intel is pushing raytracing for games. So nVidia better have a good reason to get people to still buy their boards in a few years (let's say 10) time...


it seems that we're pursuing ray tracing solely and i think it might be best to have a really good scanline renderer too...
Actually, I wasn't 100% correct, Classic uses a souped up hybrid Painters algorithm (which is close to who gfx board operate), the original 3DS Mac renderer is scanline.
However, nowadays that concept is dated and almost completely replaced by buckets (little bit if trivia: SGI & MS at one point in time were working on a tile based real time rendering architecture - I can't remember that name right now though).


so that would be... what... 3? ray trace pure. hybrid. scanline pure.

That depends on what part you look at. As soon as you start bending rays (that would include special cameras, even one "only" including lens distortion) scanline is out of the question, it just doesn't work anymore.
Slice'n'dice, the original Reyes (PR RenderMan) technique can be used by raytracers as well, as can level of detail techniques.
The nice thing about CPU based renderers is that you can make them complex and still keep them portable (mental ray) - pure GPU based ones are still a ***** to code and limited in terms of how smart you can make them.

As for faking it... I'm all for it. Being picky, I see physically accurate renderers as just a closer approximation to reality.

It's not "accuracy is for chumps" in movie making, it's more like "reality sucks" :D

Cheers,
Mike

jin choung
03-07-2008, 02:18 PM
There's one thing that shouldn't be forgotten here... intel is pushing raytracing for games. So nVidia better have a good reason to get people to still buy their boards in a few years (let's say 10) time...


not forgetting.

actually, the article in the link is a RESPONSE to the intel guy! nvidia doesn't agree... again, on universal principles in part.

also, yah, i'm not arguing at all for going with gpu rendering... just scanline on cpu as it is in "classic" prman.

jin

jin choung
03-07-2008, 02:21 PM
That depends on what part you look at. As soon as you start bending rays (that would include special cameras, even one "only" including lens distortion) scanline is out of the question, it just doesn't work anymore.

right but you don't need such things all the time. sometimes, you just want your subpixel displaced creature.

as for fast - i meant is raytraced subpixel displacement on the fastest raytracer faster than the fastest scanline?

THAT might be a compelling reason to have both. as i said, different tools for different jobs.

jin

jin choung
03-07-2008, 02:25 PM
Perhaps something similar to Renderman's deep shadows that give better shadow mapping.

that would be GREAT... but i'd just settle for nice shadow maps...

there's something up with our shadow maps. compared to maya ours looks horrible res for res and i have no idea why. hope they address that... heck, even identify that.

jin

Lightwolf
03-07-2008, 02:37 PM
as for fast - i meant is raytraced subpixel displacement on the fastest raytracer faster than the fastest scanline?

I suppose you mean Reyes, not scanline rendering (as indicated by your previous posts).
If you don't have any reflections, refractions, raytraced shadows, GI, AO, special cameras or anything else that needs raytracing... Probably.

Not necessarily though.

Raytracing can be sped up using kd-trees/octress and the like, which take a bit to set up but speed up things... and all raytraced parts profit from that.
I'm pretty sure that there are cases where a raytracer can be faster, i.e. with loads of lights in the scene (remember, if you have no raytracing you need to pre-compute shadow maps, which end up "rendering" the complete scene from the PoV of the light - raytraced lights only trace to the light source if the effect is actually visible in the scene).

But that's why there are so few "pure" renderers out there... you just end up loosing some area that is better handled using other techniques (the purest raytracer I can think of is probably Real4D (http://www.realsoft.com/) ... heck it doesn't even tesselate SubDs or NURBs, it raytraces the formula directly - quit ethe opposite of what PRMan does).

Cheers,
Mike

Lightwolf
03-07-2008, 02:38 PM
that would be GREAT...
Apparently there is an issue regarding software patents ... from what I've heard though that is related to how PRMan reduces the memory usage though - not the general technique.

Cheers,
Mike

jin choung
03-07-2008, 03:21 PM
I suppose you mean Reyes, not scanline rendering (as indicated by your previous posts).
If you don't have any reflections, refractions, raytraced shadows, GI, AO, special cameras or anything else that needs raytracing... Probably.

Not necessarily though.

Raytracing can be sped up using kd-trees/octress and the like, which take a bit to set up but speed up things... and all raytraced parts profit from that.
I'm pretty sure that there are cases where a raytracer can be faster, i.e. with loads of lights in the scene (remember, if you have no raytracing you need to pre-compute shadow maps, which end up "rendering" the complete scene from the PoV of the light - raytraced lights only trace to the light source if the effect is actually visible in the scene).

But that's why there are so few "pure" renderers out there... you just end up loosing some area that is better handled using other techniques (the purest raytracer I can think of is probably Real4D (http://www.realsoft.com/) ... heck it doesn't even tesselate SubDs or NURBs, it raytraces the formula directly - quit ethe opposite of what PRMan does).

Cheers,
Mike

did you read the linked article? nvidia talks a lot about why some of those assertions are bunk.

also, my understanding is reyes IS a scanline renderer.

as in: https://renderman.pixar.com/products/tools/renderman.html

jin

Lightwolf
03-07-2008, 04:20 PM
did you read the linked article? nvidia talks a lot about why some of those assertions are bunk.
I did... but they relate to techniques you use within the confines of realtime rendering (i.e. 40ms per frame or less).


don't exactly see a convergence, but I do believe that hybrid rendering is the future.
He's talking about the future... while that has been state of art in production renderers for the past 15 years or so (when did LW offer raytracing?).


also, my understanding is reyes IS a scanline renderer.
If you look at the site you'll see that they describe it as a "scanline" renderer, notice the quotes. It isn't in the classic sense, 3DS would be.

Cheers,
Mike

jin choung
03-07-2008, 04:35 PM
If you look at the site you'll see that they describe it as a "scanline" renderer, notice the quotes. It isn't in the classic sense, 3DS would be.

lol. ok. here it is without the quotes, from the book that i read that informed me of the fact.

i don't know what sense you're talking about it but:

http://books.google.com/books?id=6_4VaJiOx7EC&pg=RA1-PA513&lpg=RA1-PA513&dq=renderman+scanline&source=web&ots=cpXpTRHLI4&sig=w7q_OgQaTblQ-wAkh0C-OhyPG9w&hl=en

they had a big long chapter that talked about ray tracing vs. scanline, identifying prman before bmrt as scanline.

also, if you google "reyes scanline" and "renderman scanline", you'll find a lot of docs and pages that also identify pre-bmrt renderman and reyes as indeed scanline.

jin

p.s. oh, look at "reyes" in the glossary

fyffe
03-07-2008, 05:13 PM
I remember someone from ILM talking about a new system of "approximating raytracing" with a method developed by Nvidia. They used it in Pirates and some others.

They basically implemented LOD for their raytracer. Very cool, though not really "new". There are quite a few studios just getting used to the concept of (Dr. Evil quote fingers) "ray tracing". It will be interesting to see what direction NVidia takes things, what with its talk about ray tracing on the GPU and the acquisition of Mental Images.

wacom
03-07-2008, 06:11 PM
Mental ray is a scanline/raytrace hybrid.

You can turn off each one independently if you wish based on if you have a scene that is either VERY heavily ray traced, or not at all, or a bit of both.

mr uses scanline by default in most hosts until it "bumps into" some raytracing. Then it shifts over. While this speeds up certain scenes, if you know that it's going to have to swap back and forth too much you just might as well disable scanline and actually SAVE time.

Given that so much of Lightwaves renderer seems to be based around raytracing, and that shadowmaps are kind of weak in LW (but that new area light looks tasty in 9.5) I don't see the huge advantage of it going more scanline anytime soon.

As far as I know in my limited scope too, it's very...uh...wrong...to compare a reyes render engine to a more raytrace type of engine since they work so fundamentally different. It seems in a perfect world you have access to each... Plus as far as I can tell the displacement in reyes rendering is almost a side effect of how it deals with scenes in general, and its motionblur, DOF etc. are very different from how mr does it, even if in the end there are a "bunch of polygons" turned out- so those comparisons are kind of too different too.

This is just my limited understanding so far- I'm not really saying or hope it doesn't look like I'm pretending to know even more than 10% of how these things work. However, just reading the 3Delight manual a bit, and reading this book -( http://www.powells.com/biblio/61-9780470008546-0 )- has lead me to believe that there are some significant differences in these two architectures that makes comparing them like comparing apples to oranges.

Learning to leverage each one when appropriate is a seriously powerful skill to develop...

I think it's ridiculous these days to think one render can accomplish "well" all aspects of rendering esp. as merging scene data between applications and there for render engines becomes more seamless for the average 3D user.

Titus
03-07-2008, 06:12 PM
personally, i like the whole "classic" prman, pixar approach.

the only thing that matters is that it looks good for what you're going for...
FAKE EVERYTHING.... everything in moviemaking is fake anyway.... "accuracy is for chumps"... approach.

it made my heart glad to hear that one of the production mandates for rattatouillie was "if at all possible, avoid ray tracing".

It's not only on Rat, they didn't use raytrace in their first 4 or 5 movies. And also when you see SSS it's always a trick, they created their famous "gummy" shader.

jin choung
03-07-2008, 06:22 PM
yah, i know. they didn't have ray trace proper for a very long time. i believe BMRT was the result of their raytrace development.

jin

jin choung
03-07-2008, 06:24 PM
has lead me to believe that there are some significant differences in these two architectures that makes comparing them like comparing apples to oranges.


right, that's why i'm not saying that one is better than the other.... i just want the best of all worlds. the right (and faster) tool for the job.

jin

wacom
03-07-2008, 06:27 PM
I'd also like to point out that many people fall into the "one ring to rule them all" renderer approach. Of coarse every manufacture of every render engine is going to tell you it is good for every application under the sun but...

Here are the broad, and highly generalized "correct" uses for rendering engines that I've seen/read/heard about/joked about (there are always a lot of exceptions):

reyes render engines (PRman, 3Delight) - great for if you need to be able to keep dense scenes rendering in 3min a frame, on average, for a heavily CG film with a certain budget.

Heavy general use raytracers- lightwave/mr etc.- great for smaller/shorter CG sequences in films or movies and for commercial TV spots.

Vray- great for archviz

Maxwell- great for if you have all year!

This generalization though leaves out so many variables though- and while the "pixar" look is cute it just aint going to cut it for every application. That said there are soooo many renders that didn't really even need heavy raytracing...

jin choung
03-07-2008, 06:50 PM
This generalization though leaves out so many variables though- and while the "pixar" look is cute it just aint going to cut it for every application.

that's true but let's not forget that a huge chunk of ilm's output as well as stuff from many big vfx houses for photorealistic stuff is done through prman.

jin

wacom
03-07-2008, 09:31 PM
that's true but let's not forget that a huge chunk of ilm's output as well as stuff from many big vfx houses for photorealistic stuff is done through prman.

jin

I know, but if you're a staff of three people, on a tight deadline, and need it to be "real" then you might want to look at a raytracer first if you're familiar with it. Do you really think your going to get archviz people to give up kray or vray for faster motion blur, displacements and DOF?

That said, I'm not really arguing with you on that point, only that often what matters is if the client is happy and how many hours you spent on getting them the image. Cost per frame * sanity level.

I also think that there are quite a few "raytraced" car commercials out there with better cg than anything made in the same time period as far as feature films go, but that's discounting the amount of work that has to be generated in a certain time frame and budget.

Why would I waste hours on recreating "realistic" lighting for product in a print ad, when if I send off an mr or lw raytraced scene to a render farm I might be able to get the same/better image off in the same or faster time? If I had to render 300 frames or more...maybe it would be a different story...

That being said, I personally find it harder to create and control more creative lighting with things like FG and monte carlo radiosity. So if the look doesn't need to be "more than real" I'm more than happy to try and "paint the scene with lights." For those scenes I'd love to use a reyes render engine!

jin choung
03-07-2008, 09:36 PM
just countering the notion that scanliners need be stylized cartoon cute.


This generalization though leaves out so many variables though- and while the "pixar" look is cute it just aint going to cut it for every application.

jin

Lightwolf
03-08-2008, 05:52 AM
also, if you google "reyes scanline" and "renderman scanline", you'll find a lot of docs and pages that also identify pre-bmrt renderman and reyes as indeed scanline.
Ah, allright, they classify REYES as a special kind of scanline, which is fine. That doesn't mean that the opposite is true... scanline rendering does not automatically give you the capabilities of a REYES renderer though.

Cheers,
Mike

wacom
03-08-2008, 02:00 PM
Ah, allright, they classify REYES as a special kind of scanline, which is fine. That doesn't mean that the opposite is true... scanline rendering does not automatically give you the capabilities of a REYES renderer though.

Cheers,
Mike

Double triple "WORD" to your render farm server!:agree:

jin choung
03-08-2008, 02:38 PM
Ah, allright, they classify REYES as a special kind of scanline, which is fine. That doesn't mean that the opposite is true... scanline rendering does not automatically give you the capabilities of a REYES renderer though.

Cheers,
Mike

i didn't claim that it did, did i?

jin

Verlon
03-08-2008, 03:32 PM
The scary part of this is how much Lightwolf seems to know about all of it off the top of his head. :)

Seriously, I agree with the direction LW is taking. If you had a magic genie CPU and you could render ANYTHING at 60FPS, well which one would you normally prefer?

I think the reason the production houses are avoiding raytracing doesn't have to do with the look so much as the time required. If the time issue can be corrected to an acceptable level, raytracing would be the preferred tool.

If my choices for the next LW release are "Improved scanline renderer" OR one of the following: faster radiosity, Viper II, improved CCs, faster bones, hair/fur that reflects/refracts, streamlined workflow, or any of dozens of other features --

Well I would not pick "improved scanline renderer." Now I understand that LW devs work on specific parts of the application, but I would still rather have faster radiosity than faster scanline -- every day, and twice on Sundays.

jin choung
03-08-2008, 03:40 PM
I think the reason the production houses are avoiding raytracing doesn't have to do with the look so much as the time required. If the time issue can be corrected to an acceptable level, raytracing would be the preferred tool.

lol... but not in a mean way... this just really genuinely made me laugh.

YES!

AGREED!

but that's the thing, *I* don't have unlimited time either. time is INDEED a factor for me and my work and so if i can "cheat" instead of brute force ray trace, i often take the cheat.

true, sometimes raytracing can be "fire and forget" and requires less thought but other times, it can take an exceeding long time to "set up" because every test render to see what it's gonna look like takes longer. necessitating things like fprime - which can introduce yet other issues regarding compatibility and plugins and such....

so given that some effects can be had for cheaper with scanline, i personally think it's worthwhile... especially since we don't have those certain effects in raytrace yet....

as i said, personally, having an "open render api" that allows for swappable render solutions (the three i'm advocating be in there out of box being raytrace, hybrid and scanline) sounds like a good idea to me.

BUT

i understand why newtek would go the route they're going by just improving raytrace... if a big chunk of their business is coming from selling infinite render node capability so that places that use things like maya (which already have strong scanline renderers), then they'd make more money just tweaking the heck out of the raytracer....

jin

RedBull
03-08-2008, 03:47 PM
so that places that use things like maya (which already have strong scanline renderers)

ROFL, That was also funny.....

Compared to LW, you think Maya's scanline is strong, yeah about as strong as Max's :) That's the whole reason MR was bought and integrated to Maya and Max in the first place.

Lightwolf
03-08-2008, 04:36 PM
i didn't claim that it did, did i?
No, but you mentioned scanline as beeing the bee's knees ... while you were specifically mentioning REYES advantages. I'll omit the car analogy - you can make up your own ;)

...all is well :)

Cheers
Mike

Lightwolf
03-08-2008, 04:45 PM
especially since we don't have those certain effects in raytrace yet....
Hm, we don't - but others do.
So it might just be a viable solution to add sub-pixel displacement to LW - instead of completely changing the render architecture back to '84 style PRMan while PRMan catches up on the raytracing front ;)

Hey, 9.5 will have a light SDK... who knows, there might be sombody out there who'll write lights with deep shadow maps (and loads of other nice tricks). That's a big leap forward.

One more thing concerning speed... a few years ago there was a demo that showed off distributed PRMan, that basically used a farm to render interactively. Surprisingly it took a _lot_ of nodes to get near FPrime performance on a single machine. And if you think that might be due to REYES... modo renders interactively as well (slower than FPrime though).

However... PRMan has the huge advantage or programeability (sp?) - as does mental ray (which is also a reason for the wide spread use of Maya ... all of these are great platforms for code and custom pipelines). I think that plays a huge role in larger studios using them as well (then again Blue Sky just use their own renderer because they focus on GI).

Cheers,
Mike

Lightwolf
03-08-2008, 04:49 PM
The scary part of this is how much Lightwolf seems to know about all of it off the top of his head. :)
Lol... I just luuuurve the subject and have followed the field/publications for ages (rendering just by itself is a huge topic).

In the end it is a matter of priorities and trade offs.. and it seems that every renderer out there has areas where it excels, while at the same time having weaknesses in others...

Cheers,
Mike

jin choung
03-08-2008, 06:17 PM
No, but you mentioned scanline as beeing the bee's knees ... while you were specifically mentioning REYES advantages.

like what?

jin

jin choung
03-08-2008, 07:06 PM
Hm, we don't - but others do.
So it might just be a viable solution to add sub-pixel displacement to LW - instead of completely changing the render architecture back to '84 style PRMan while PRMan catches up on the raytracing front

again, along the spirit of the answer i gave to verlon, if there is no advantage at all to be gained by having a scanliner, it would be utterly ridiculous to ask for it now.

but then the question becomes again - in a shootout in rendertime displacement (among other issues not mentioned) between a raytracer and a scanliner, is there a non-negligible speed gap?

and changing the render architecture COULD mean changing the current, actual rendering code (not what i propose) but it could also mean changing lw so that it can have hot swappable renderers?

so that lw's current hybrid renderer becomes a simple BLACK BOX among others that can be plugged in at will. call me crazy but that sounds like a good option regardless. UNLIKELY but nonetheless good.
-----------------------------------------------------------------------

as for prman '84... well as i said earlier, one of the pixar's mandates for rattatouille (2007) was to avoid ray tracing as much as possible.

unlike some, pixar (while fully pursuing the technology now to have as part of their arsenal) seems not so enamored with ray tracing that they believe that it is the end all be all, bee's knees solution to all things rendering.

so if a non ray tracing scanline solution (mentioned with full recognition that prman categorizes itself as REYES which itself can be understood as a subset of scanline renderers [to be exhaustingly clear... sigh]) hearkens back to 1984 to you, evidently, that 1984 technology still provides compelling usability in this day and age to pixar.

with whom, i am inclined to agree.

finally,

In the end it is a matter of priorities and trade offs.. and it seems that every renderer out there has areas where it excels, while at the same time having weaknesses in others...

hey, imagine that... that's what i'm saying. and if we can have other options to address current weaknesses, all the better eh?

jin

Verlon
03-08-2008, 07:38 PM
I just feel that any resources that could be thrown at improving the scanline renderer would be better directed at a faster ratrace renderer (Arch-Viz guys, can I get an "Amen Brother!"). Now if, in the course of WORKING for a faster raytracer, they HAPPEN to find a way to make the scanline better, by all means add it. I would in no way ask a team to dedicate to improving the scanline renderer when many more people, including you, I think, Jin, have been unsatisfied with the speed of the radiosity renders.

As I mentioned earlier, if the guys somehow found a stopping point on the raytracer, I would (if I were in charge), tell them to work on the VIPER system instead.

If the team/guy/whatever working on the openGL preview found a way to make the scanline renderer better somehow, put the code in and write them a bonus check. BUT, I would rather have a better openGL preview than a better scanline renderer (because that is about all I use scanline for these days anyway -- things that can't be done in VIPER or FPrime and take too long to preview in raytrace).

If I had WAY more resources than NT, I would STILL put those things I listed ahead of the scanline renderer. If I still had a couple of guys left over, then I would consider it....maybe with the GPU integration thing from another thread....that might be worth it.

Titus
03-08-2008, 09:13 PM
yah, i know. they didn't have ray trace proper for a very long time. i believe BMRT was the result of their raytrace development.

jin

Not exactly. BMRT was the PhD work of Larry Gritz, he wrote a "plugin" for RenderMan to make raytrace calls. They used it only on one scene in A Bug's Life and that's all.

When RenderMan finally got raytracing a few years ago it was really slow and even then Pixar decided to use it the less possible.

Titus
03-08-2008, 09:19 PM
One more thing concerning speed... a few years ago there was a demo that showed off distributed PRMan, that basically used a farm to render interactively. Surprisingly it took a _lot_ of nodes to get near FPrime performance on a single machine. And if you think that might be due to REYES... modo renders interactively as well (slower than FPrime though).


This demo was a proof of concept (presented as a stupid trick), it says nothing about RenderMan. I'm sure with more time they could end with something fast as FPrime.

jin choung
03-08-2008, 11:24 PM
hey verlon,

well, for folks really into doing character animation with hi res creature models, i'm sure their priorities would bend more toward the scanline renderer (for rendertime displacement)... or put in a fast implementation in current renderer lacking that.

also, a lw architecture that can break out the renderer into an encapsulated black box system would benefit from enabling people to write whatever kind of renderer they please... so i still think that's a good idea.

but i'm not holding my breath.

i still think that we're losing out BIG-TIME by not having a modern day RENDER-GL! that's an idea whose fullness of time has come NOW with directx10 class GPUs... you can do an AWFUL lot of gpu renders that are perfectly suited to production fast fast fast.... but alas, we lack.

jin

dballesg
03-09-2008, 01:28 AM
i still think that we're losing out BIG-TIME by not having a modern day RENDER-GL! that's an idea whose fullness of time has come NOW with directx10 class GPUs... you can do an AWFUL lot of gpu renders that are perfectly suited to production fast fast fast.... but alas, we lack.

jin

Didnt LW 5.6 included a system called exactly that? Render-GL. If I remember well was developed by Intergraph but for some reason was abandoned on LW 6 I think.

jin choung
03-09-2008, 01:30 AM
yup. it was ahead of its time... well not really, it did what it was supposed to do....

but now, if we had it NOW, it could actually serve as a replacement renderer for lots of shots.... modern ogl directx stuff can be very "good enough" and extremely fast.

jin

Sensei
03-09-2008, 04:03 AM
also, a lw architecture that can break out the renderer into an encapsulated black box system would benefit from enabling people to write whatever kind of renderer they please... so i still think that's a good idea.


You can do any type of 3rd party renderer in LW since at least LW 5.6 or 6.0, as long as it's "press button to start" type of renderer like Kray or FPrime Render.. The only good reason to make renderer plug-in class is to have 3rd party renderer called from LWSN. And VirtualRender is such bridge to allow itself and other 3rd party renderers to be integrated into LW rendering pipeline.

Lightwolf
03-09-2008, 06:04 AM
like what?
*sigh* sub-pixel displacements. Those are inherent to REYES, not a general property of scanline renderers.

Cheers,
Mike

Lightwolf
03-09-2008, 06:26 AM
again, along the spirit of the answer i gave to verlon, if there is no advantage at all to be gained by having a scanliner, it would be utterly ridiculous to ask for it now.

but then the question becomes again - in a shootout in rendertime displacement (among other issues not mentioned) between a raytracer and a scanliner, is there a non-negligible speed gap?
There is a speed gap, as mentioned below, it is a trade-off. Would you prefer a less capable, more specialized and thus faster renderer that doesn't cover all situations... or a slightly slower but more capable monster?
Of course, a pure scanline renderer would even be faster than PRMan... but you wouldn't see any sub-pixel displacements. Add raytracing to REYES and it slows down as well. Depending on the pre-processing time needed for the shadow maps, you can bring down PRMan to its knees as well.
mental ray is quite good raytracing displacements, GI, caustics etc... but slows down massively if you want decent motion blur... where LW comes in.

And we haven't even touched the possibilities to speed up raytracers like ray caches (re-use already traced rays for similar evaluations).

and changing the render architecture COULD mean changing the current, actual rendering code (not what i propose) but it could also mean changing lw so that it can have hot swappable renderers?
It has changed already. And from what I undertsand the rendering core has already been extraced from LW - however, there is no official mechanism to swapin a third party one.

as for prman '84... well as i said earlier, one of the pixar's mandates for rattatouille (2007) was to avoid ray tracing as much as possible.
Well, of course... PRMan has a huge speed penalty when raytracing. If I'd use PRMan I'd avound raytracing as well. Again, it's the trade-off issue. You either get the renderer that makes sense for your needs (if you have the option) or limit yourself (is Pixar did).

Blue Sky uses GI on all shots, because that is the strength of their renderer. They might avoid other features though that penlize their renderer.

unlike some, pixar (while fully pursuing the technology now to have as part of their arsenal) seems not so enamored with ray tracing that they believe that it is the end all be all, bee's knees solution to all things rendering.
I don't think anyone does... it is just a matter of priorities. I know a few, even fairly small, studios that just pick renderers by shot, depending on what they need (Maya based studios).

so if a non ray tracing scanline solution ... hearkens back to 1984 to you, evidently, that 1984 technology still provides compelling usability in this day and age to pixar.
Raytracing goes back quite far as well. Heck, we still use Blin/Phong shading which goes back to '77.

I don't see a reason for Pixar to drop their own renderer... but that doesn't mean much - it is their own package (like I see no reason for Blue Sky to drop theirs). And there are compelling reasons for others to use it as well (after all, it has a long history, plenty of trained TDs, crucial stuff in production).
Nonetheless, that doesn't mean that newer technology might not make more sense for a package like LW.

I just don't see it as a black and white REYES vs. raytracing issue... since most renderers use either technology as they see fit.

Now, saying you'd like a third party API to swap out the renderer, or if you'd like to see bucket rendering in conjunction with sub-pixel, render time displacements - then I'd fully agree. And I couldn't care less if it is completely raytraced or not - as long as it performs (PRMan 13.5, just released, is apparently finally completely optimized for multiple threads/cores and scales quite well.).

Cheers,
Mike

Lightwolf
03-09-2008, 06:28 AM
This demo was a proof of concept (presented as a stupid trick), it says nothing about RenderMan. I'm sure with more time they could end with something fast as FPrime.
Which is what modo does now. The point it though that there is other, compelling technology out there that is based on different concepts... and works just as well.

The result matters, not the technology. (and I'm pretty sure jin will actually agree with me here ;) ).

Cheers,
Mike

Titus
03-09-2008, 10:23 AM
The result matters, not the technology.

I thought this point was clear by now.

Titus
03-09-2008, 10:25 AM
double post

Lightwolf
03-09-2008, 10:47 AM
I thought this point was clear by now.
I thought that was clear before the first post ;)

Cheers,
Mike

Elmar Moelzer
03-09-2008, 12:57 PM
People should not believe everything some marketing bloke lets out...
All I am going to say about it!
Love Nvidia, but do not aggree with everything they say and take everything anyone from any company says with a grain of salt.
Just something to think about:
I do not know of any way to make Progressive rendering work with scanline rendering.
CU
Elmar

Lightwolf
03-09-2008, 01:03 PM
People should not believe everything some marketing bloke lets out...
Uh oh.... Elmar, dear Elmar :p :
Dr. David Kirk, Chief Scientist of NVIDIA
http://www.nvidia.com/object/bio_kirk.html

Now, if it was some marketing person, I'd agree :D

Cheers,
Mike

Lightwolf
03-09-2008, 01:08 PM
(little bit if trivia: SGI & MS at one point in time were working on a tile based real time rendering architecture - I can't remember that name right now though)
Just for completeness sake, since I stumbled across it: It was Fahrenheit (http://en.wikipedia.org/wiki/Fahrenheit_graphics_API).

Cheers,
Mike

Elmar Moelzer
03-09-2008, 01:40 PM
Well, whatever chief scientist that is, I still take it with a grain of salt, unless he is working for an independent university, or something.
Nvidia is in the business of making scanline rendering accelerators (to simplify it a lot), not raytracing accellerators. Of course they wont say anything that could potentially harm their business. And who says, that whatever Mr chief scientist said was not prewritten by some marketing fuzzy before.
In any case, I am not a big fan of scanline and pretty much consider it dead (for non realtime or gaming applications as these are a completely different matter all together). But thats just my personal opinion.
CU
Elmar

jin choung
03-09-2008, 04:49 PM
*sigh* sub-pixel displacements. Those are inherent to REYES, not a general property of scanline renderers.

Cheers,
Mike

oops. you're right. i was too specific. i was thinking along the lines of maya's support for displacement shaders and its "feature based displacement".

jin

jin choung
03-09-2008, 04:51 PM
The result matters, not the technology. (and I'm pretty sure jin will actually agree with me here ;) ).

i do. and that's the pixar position as well.

and that is pretty much the point of the first post.

jin

Lightwolf
03-09-2008, 04:51 PM
oops. you're right. i was too specific.
Let me just nitpick once more... too general, not too specific ;)

Yeah, I'll go away and shut up now :D

Cheers,
Mike

jin choung
03-09-2008, 04:53 PM
Which is what modo does now. The point it though that there is other, compelling technology out there that is based on different concepts... and works just as well.

and that may be true but again, i come back to the issue of speed. is it as fast? if so, great, let's go with that. (more on this on next reply)

jin

jin choung
03-09-2008, 04:55 PM
Let me just nitpick once more... too general, not too specific ;)

Yeah, I'll go away and shut up now :D

Cheers,
Mike

??? depends on what you're talking about... i was too specific in indicating "subpixel displacement" when i should have been stating the more general advantage of displacement shader.

jin

Lightwolf
03-09-2008, 05:02 PM
and that is pretty much the point of the first post.

Ah, sorry then, I read the opposite into it:

...it would be nice if lw was pursuing scanline rendering as a parallel development path...
as opposed to:
"I'd like to see that..."

...we get things like micropolygon dicing for things like sub-poly displacement
(which you can get without REYES).

I guess I was concentrating too much on the first part of the post then...

Is'n this purely textual communication fun?

Cheers,
Mike

jin choung
03-09-2008, 05:02 PM
There is a speed gap, as mentioned below, it is a trade-off. Would you prefer a less capable, more specialized and thus faster renderer that doesn't cover all situations... or a slightly slower but more capable monster?


why not have BOTH?

that's what i'm advocating. we already have our raytrace hybrid. i'm NOT saying we should dump it.

but if we can have a less capable, more specialized, faster renderer for things like rendering high res characters with shadow maps, displacement shaders, reflection maps and nothing else... why not?

again, if modo can provide all that at no speed penalty (vs. say, the maya scanliner), then yes, let's do that too... stuff what i'm asking for into our existing renderer.

BUT - if a pure scanliner can do it FASTER... that's NOT a moot point imo.
-----------------------------------------------------------------

finally, yes, limited and specialized. but per the point that you, i, felipe and pixar agree on, it is the look that counts.

jin

jin choung
03-09-2008, 05:04 PM
as opposed to:
"I'd like to see that..."


wow... i don't see the difference on this point at all.

jin

Lightwolf
03-09-2008, 05:04 PM
??? depends on what you're talking about...
What I quoted... you were too general by mentioning scanline, while it is specifically REYES that allows for (sub-pixel) displacements. Vanilla scanline doesn't.

Cheers,
Mike

jin choung
03-09-2008, 05:06 PM
What I quoted... you were too general by mentioning scanline, while it is specifically REYES that allows for (sub-pixel) displacements. Vanilla scanline doesn't.

Cheers,
Mike

as i said, it depends on how you look at it. i was too specific by mentioning "subpixel displacement" instead of displacement shader or even feature based displacement.

jin

Lightwolf
03-09-2008, 05:11 PM
wow... i don't see the difference on this point at all.
Don't start coding then ;)
Your sentence was a request for a specific rendering technology that you thought would get you sub-pixel displacements - but it doesn't automatically (only a specific subset of that tech does).

So, that's a request for tech.

Saying: "I'd like to have sub-pixel displacements - regardless of how it is implemented as long as it is fast enough"

That's "The result matters, not the technology".

Cheers,
Mike

P.S. I'm puzzled at the link to the article though, since it doesn't mention sub-pixel displacements at all...

Lightwolf
03-09-2008, 05:15 PM
again, if modo can provide all that at no speed penalty (vs. say, the maya scanliner), then yes, let's do that too... stuff what i'm asking for into our existing renderer.
I never benchmarked the two, so I can't compare them.

finally, yes, limited and specialized.
That would pose the question of marketability. Would you be willing to shell out big bucks (small market) for a renderer that supports, say a third of the built in one, but renders twice as fast?
FPrime and KRay come to mind here...

Cheers,
Mike

jin choung
03-09-2008, 05:16 PM
Don't start coding then ;)
Your sentence was a request for a specific rendering technology that you thought would get you sub-pixel displacements - but it doesn't automatically (only a specific subset of that tech does).

So, that's a request for tech.

Saying: "I'd like to have sub-pixel displacements - regardless of how it is implemented as long as it is fast enough"

That's "The result matters, not the technology".


your post is only true if there is NO SPEED DISCREPANCY. i assume that there is. is there not?

and the link is NOT specifically about subpixel... it's about the point that i said it argued for... that it's the look that matters, not the technology. and the point of the article is that ray tracing is not the end all be all....

jin

Lightwolf
03-09-2008, 05:17 PM
i was too specific by mentioning "subpixel displacement" instead of displacement shader or even feature based displacement.

Absolutely not. You could (arguably) attribute the latter two to LW even at this stage - the first one ... no way.

Cheers,
Mike

jin choung
03-09-2008, 05:22 PM
You could (arguably) attribute the latter two to LW even at this stage - the first one ... no way.


i (arguably) do not.

especially as it pertains to scanliners' speed advantage in this regard.

jin

jin choung
03-09-2008, 05:29 PM
to address a point of disconnect that i think we've hit:

- i am NOT arguing that we should have a scanliner for the sake of having that technology.

- i am arguing that we should have it because while it is much more limited it can be much much faster... while creating images that are just as beautiful and/or appropriate.

so it's the results that matter - and i figure SPEED into the results.

jin

p.s don't worry though... i seriously doubt we're gonna get it... but in lieu of that, i would like nicer looking shadow maps.

Lightwolf
03-09-2008, 05:33 PM
it's about the point that i said it argued for... that it's the look that matters, not the technology. and the point of the article is that ray tracing is not the end all be all....

It is also about 3D engines related to gaming where a lot of things we care about don't matter or don't matter as much (AA & motion blur come to mind).

Nobody said ray tracing is "it" ... but there's little reason for a renderer to not be based on it at the current state of technology and users expectations.

If you look at the article again, just as he accuses intel of neglecting advances in their engines he's also neglecting advances in raytracing based engines. That might make sense for that intel is developing... but that's as far as it goes.

Compared to that what either are doing, current production renderers are a few generations ahead.

As for the speed difference... I don't think there is a huge one... I'd love to run modo agains PRMan for example to see what happens... but even that test is likely to be inconclusive as there's plenty of other variables that affect speed (i.e. PRMan and mental ray can both undersample, effectively evaluating surface shading for more than one pixel at a time, AA comes into play as well).

Cheers,
Mike

Lightwolf
03-09-2008, 05:43 PM
- i am NOT arguing that we should have a scanliner for the sake of having that technology.
I got that, because then you could just go back to rendering everything in Classic Camera ;)

I am arguing that we should have it because while it is much more limited it can be much much faster...
Basically we're just arguing the "much much" ... And of course there's a "much much faster" when comparing any renderer X to Y (the inverse as in "much much slower" is also true). The question is... how much does it matter? Is it crucial enough for users to stick with what they know and go through the pain for a shot or two? Or should they just switch packages because they have different needs anyhow? How many studios switch renderers on a shot by shot basis to get the best out of the shot? (project by project happens)

I suppose, in the end, if you absolutely need PRMan, get a coder to hook up LW or switch packages. Or get something custom written that is even faster (and more limited). It doesn't make a lot of sense for NT to strip it down though (Remember the fuss about FPrime not completely supporting LW features?).

Cheers,
Mike

jin choung
03-09-2008, 05:49 PM
It is also about 3D engines related to gaming where a lot of things we care about don't matter or don't matter as much (AA & motion blur come to mind).

and as i said earlier, i thought the article is interesting because some of the critiques he makes about ray tracers are general and not specific to game engines or real time. and other critiques within the context of gaming can still have wider repercussions.


Nobody said ray tracing is "it" ... but there's little reason for a renderer to not be based on it at the current state of technology and users expectations.

that sounds like you're saying two opposite things at once. it does sound like you're saying ray tracing is pretty "it"....


As for the speed difference... I don't think there is a huge one... I'd love to run modo agains PRMan for example to see what happens... but even that test is likely to be inconclusive as there's plenty of other variables that affect speed (i.e. PRMan and mental ray can both undersample, effectively evaluating surface shading for more than one pixel at a time, AA comes into play as well).

well that's the big point of contention then isn't it? within a more limited feature set, if there is no speed advantage, there is no issue and no need to even think to desire a non-ray tracer.... but that remains to be seen.

jin

jin choung
03-09-2008, 05:50 PM
right. as you said, the issue here is "much much".

jin

wacom
03-09-2008, 06:37 PM
We've all got to get on the crusade to end arguments like this in CG- this render engine is entirely better than that render engine types of arguments.

While some in general are better than others, for certain things, we seem to often leave out some important things, namely, what in the hell are you trying to render, at what size, and in what time frame? Add budget and it gets even more complicated.

Case in point: While mr does circles around lightwave when it comes to doing displacement in general...it kind of sucks in the obvious area of...bump maps! Yeah, kind of sucks to have to use normal maps all the time to get the speed you get normally from most renderers...there are "work arounds" but as any LWer knows...those are kind of sorry at times... In fact, bumpmaping is so slow, some mr gurus just go straight to displacement when ever they can.

If we though compare mr simply on displacement and bump mapping to 3Delight...well then mr looks like the slow poke...add raytracing though and it might be the slow poke. That could all change though depending on what your rendering, the size of the render, and if you're doing it over a network etc.

I'll admit I was guilty of being in on these arguments whole sale even just a few years ago- but after reading about and using a few different engines for more than just a simple turn table render I've seen the light- and hate to paint such things with a broad brush all the time.

The whole realtime video card CG thing vs. standard software render is ridiculous BTW. Those engines cut soooo many corners etc. and have such a different purpose that you shouldn't compare them. Plus, software renderers always will be adding more and more advanced shader and general rendering features that will only slowly trickle down to real time ones. There isn't even a realtime card yet that could do toy story faithfully yet- so who's ahead of the curve in those regards?

wacom
03-09-2008, 06:41 PM
The whole realtime video card CG thing vs. standard software render is ridiculous BTW. Those engines cut soooo many corners etc. and have such a different purpose that you shouldn't compare them. Plus, software renderers always will be adding more and more advanced shader and general rendering features that will only slowly trickle down to real time ones. There isn't even a realtime card yet that could do toy story faithfully yet- so who's ahead of the curve in those regards?

OK, I painted a broad stroke on that one...problem is I think/feel/know it's really true!

jin choung
03-09-2008, 09:10 PM
yeah... wow.

i'll just reply to your post with your own post.


While some in general are better than others, for certain things, we seem to often leave out some important things, namely, what in the hell are you trying to render, at what size, and in what time frame? Add budget and it gets even more complicated.


it depends on what you're trying to render.

and for some things... perhaps just elements in a wider shot, having the ability to RENDERGL with current opengl features may be sufficient.

and if you add in the consideration that with a rendergl implementation, we don't care about REAL TIME output, you can get really good results if you allow a frame to go for a few seconds!

in any case, the option would be nice.

jin

Sensei
03-10-2008, 12:58 AM
Case in point: While mr does circles around lightwave when it comes to doing displacement in general...it kind of sucks in the obvious area of...bump maps! Yeah, kind of sucks to have to use normal maps all the time to get the speed you get normally from most renderers...there are "work arounds" but as any LWer knows...those are kind of sorry at times... In fact, bumpmaping is so slow, some mr gurus just go straight to displacement when ever they can.


If bump map is supported natively by renderer it is converted to normal map during rendering, for every single sample (usually requires to take 6 times as much of color map, 3 times subtract them, and normalization of vector that requires slow sqrt() function).. Implementing just normal mapping and forcing user to convert bump map to normal map off-line is for his good- lower frame render time..

Lightwolf
03-10-2008, 02:44 AM
If bump map is supported natively by renderer it is converted to normal map during rendering, for every single sample (usually requires to take 6 times as much of color map, 3 times subtract them, and normalization of vector that requires slow sqrt() function)..
Of course a normal map also needs a lot more memory.
(btw, 3-4 samples are enough for images).

Cheers,
Mike

dsol
03-10-2008, 05:34 AM
little bit if trivia: SGI & MS at one point in time were working on a tile based real time rendering architecture - I can't remember that name right now though).

That would be Talisman. Interesting project. Beyond the more traditional 3D techniques, they were trying to do wacky stuff like handle near-planar transforms of 3D objects by caching isolated object (2D) renders and then using bitmap rotation/scaling/translation (like a 2D post-processing app or Photoshop!). Sounds like a pretty terrible idea, and hey - it never saw the light of day, so maybe it was!

Lightwolf
03-10-2008, 05:38 AM
That would be Talisman.
Bingo... thanks.

Cheers,
Mike

dsol
03-10-2008, 08:50 AM
Just for completeness sake, since I stumbled across it: It was Fahrenheit (http://en.wikipedia.org/wiki/Fahrenheit_graphics_API).

Cheers,
Mike

Oh yeah - of course. I'd forgotten about that. The MS/SGi attempt to create a replacement for OGL. Wonder if any/much of the research that went into that ended up in OGL 2.0 and DirectX 9?

Talisman was a hardware project, and come to think of it, I don't think SGI had anything to do with it. IIRC It might even have been a MS and IBM joint project.

Lightwolf
03-10-2008, 08:55 AM
Talisman was a hardware project, and come to think of it, I don't think SGI had anything to do with it.
http://en.wikipedia.org/wiki/Microsoft_Talisman seems to be a decent enough overview.
Surprisingly they attempted to take a route that a lot of the current production renderers are taking as well...

Cheers,
Mike

wacom
03-10-2008, 12:15 PM
If bump map is supported natively by renderer it is converted to normal map during rendering, for every single sample (usually requires to take 6 times as much of color map, 3 times subtract them, and normalization of vector that requires slow sqrt() function).. Implementing just normal mapping and forcing user to convert bump map to normal map off-line is for his good- lower frame render time..

Understood, but sometimes you just want to use a 3D procedural with spacial mapping and don't want to have to bake out everything. OR you only need to render 1 frame where it's a very subtle effect and getting it to a client will be faster by just using a bump map straight up instead of dicking around with a normal map. Also- I'm saying mr is SLOWER doing bumpmaps than LW and much slower than 3Delight. Doesn't mater what the bump is. The only "saving grace" is when you need to deal with filtering on certain glancing angles with bumps etc.- then mr does well. Still...really Sensei, it's DOG slow compared to anything I've ever used for bump maps (that includes 3DS DOS)!

Just saying I'd like to have the option of using them more in mr than I do...zbump helps (by BenR- wonderful guy BTW), which is now the native bump mapping but...

Maybe mr just evaluates more at render time than the average render engine when it comes to bump maps and is more correct in a sense...but I use bumps as the cheap and dirty trick they are- and want them FAST(er).