What difficulties? The company were I currently work uses a lot of DSOs. Both (RSL) shadeop(s) (plugins) as well well as procedural primitive ones. This company also only uses PRMan (and hence the entire pipeline is designed around it). Nevertheless I can render any RIB depending on all these DSOs with 3Delight w/o a problem.
implicit surface and plugins fluid are a lot better in Prman, we had lot of problems with 3delight test.
As 3Delight does't support implicit fields plugins, I'm surprised that you manage to test this. ;)
Prman offer new feature not provided by 3delight. including point cloud and brickmap ( I know point cloud are structured in 3delight , but now it’s also the case in Prman 14.)
Careful, you are breaking your NDA here and Pixar is watching this board. :p
Firstly, PRMan 14 isn't available as we are debating this. Maybe 3Delight 7.5 will have all features of PRMan that it currently hasn't (including implicit field plugins). Who knows? We should stick to the facts at hand about products available for purchase at this point in time, not the future.
3Delight has brick maps as well. And yes, their point clouds have been stored in spatiall data-structure with lazy loading support from the beginning (i.e. their first implementation) ...
Prman offer new rsl shading language with co shader and all that. maybe you don’t use it but we use it a lot and specially for relighting engine.
Yes, co-shaders are nice but they were also overdue. If the RI spec was run by an open group instead of being a dead horse, more or less, something like co-shaders would have been added years ago.
I would also think there is a lot of problems with Pixar's current co-shader implementation. For starters, the co-shader handle list is global (co-shader handles need to be unique). Really a bad design mistake imho.
Co-shader handles are strings. This should be a specific type for obvious reasons.
There are also many bugs that get slowly fixed.
Check the Pixar forums for a lot of the issues Pixar's implementation has (some stuff obviously only gets reported in the confidential forums for individual clients). Just for example, one of our TDs posted another problem last week about passing [i]this[/i] to a co-shader to allow reverse interrogation (from co-shader to calling shader). This doesn't work.
I would think that by the time Pixar has smoothed out all these issues (and co-shaders become actually set & stable enough to use them in real production), 3Delight will have them as well.
And I'm also quite certain that when 3Delight adds co-shaders, their implementauion will not only be more solid (as in: suffering from less glitches, bugs and oversights) than Pixar's, but it will also allow for some obvious uses of co-shaders Pixar has missed so far.
Missed not because they don't have enough bright people working there, but missed because of the rushed introduction of half-baked features into PRMan lately.
A rhetorical question about this in light of the debate at hand: [i]PRMan did not support co-shaders between its initial release in 1989 and late 2007[/i]. How did you ever get something done before August 2007 if you depend on them so much that you actually list them as a reason to use PRMan over 3Delight? :)
[left]I recall a time when any PRMan release Pixar put out contained primarily new features Pixar had been using (and thus testing & improving) in-house, on their own shows, for at least a year.
These days it seems as if Pixar implemented features and released them straight away to their clients.
Unfortunately it also appears as if their level of excellence in design of new features and the general QA in software development doesn't live up to such a fast-paced developement & release cycle. I really think that it would be much better for PRMan, as a product, if Pixar went back to their previous, slower development model. The hindrance here might be that in recent years PRMan has actually come under heavy fire from the competition ...
I was scared when Pixar announced that they wanted to increase the pace even more. At the London RMan user group meeting last fall, Pixar actually said that they would try to release PRMan 14 much earlier and have a beta ready by the end of January. Luckily (for the quality of their product), they didn't keep that schedule.
There was a time, not many years ago, when people would say that the difference between using the latest PRMan release and the latest mental ray release was mainly that. PRMan was rock solid, mental ray's lates features needed to "settle" for a year before they were ready for prime time. These days I'm not so sure this distinction still applies.
Lots of features added to PRMan in recent years were like bananas -- they ripended at the client's side and the latter party had to bear the grunt of dealing with the implications.
Prominent examples are:
[li]Point clouds (not spatially loaded, issues persists since they got introduced over 3 years ago)[/li][li]Brick maps (suffer from interpolation artifacts since they got introduced 3 years ago. a “fix” was rolled out in PRMan 13.5 in late 2007 but there are still visible artefacts in some circumstances)[/li][li]subsurface scattering (prone to artifacts if diffuse mean free path is smaller than shading rate, implications are insane point cloud sizes and slow processing – almost unsuable for look dev & production for these reasons. These issues exist since almost 3 years and it doesn’t look like they will be fixed in PRMan 14).[/li][li]Co-shaders & shader classes are the latest “problem child”. Great as a feature & much needed indeed. But they feel like they would have required some time “to ripen” at Pixar, before they were ready “to pluck” …[/li][/ul]There are regularly QA issues. PRMan 13.5.2 made our entire farm go tits up when we rolled it out one cursed Friday. We lost almost one day of render time for all affected shows (300 people at least) and went straight back to 13.5.1 on Saturday.
I also think not many people actually test the latest PRMan even against the previous version. It took someone from MPC almost [i]five months[/i], from the release of PRMan 13.5, to realize that Pixar had totally fuc5ed up the AOV sampling code in 13.5.
The result was an [i]up to 400% increase in render time[/i] for one of the most used features in film VFX production with this renderer. Check the Pixar forum for the thread called "Additional AOV's take longer in prman 13.5 than in 13.0.4"[b]. [/b]The absolute effect on our own renders here was just below 300%, at the time.
In other words: there were all these big VFX houses around the world (including the company I work for) that for months got roughly 300% increased render times with AOVs, after updating to PRMan 13.5. And only one company noticed, and even they took 6 months to do so!!!
If people have that much transparency on how the renderer they use every day performs, from version to version, I can deduce that they have probably zero base of comparison for how well (or bad) it performs, compared to any other renderer (e.g. 3Delight).
DSO are multithreaded in simd process in prman. the raytracer is slow in Prman that’s why we created a custom raytracer which is faster.
So you're saying that instead of using something better (e.g. 3Delight), you wrote a way around it. That will make Pixar happy. Not only do you throw money at them for a renderer that partly isn't good enough for what you need it to do, you also spend more (of your own) money developing a custom solution around this issue. :)
The powerfull array included in rsl in Prman is very usefull and powerfull. you have a lot of features unavailable in 3delight.
Even w/o using double positives desperately trying to disguise themselves as pleonasms, I can say: SL arrays indeed are available in 3Delight. :)
Speaking of features unavailable in some renderer and available in the other: what about display subsets & exclusive displays? They are in 3Delight since years. PRMan can't even calculate the coverage (alpha) of an AOV in 2008.
This is the most powerful feature from a production perspective I've seen added to any renderer since probably almost a decade. If I had to choose between that and e.g. co-shaders, I'd always choose the displays subsets.
Where you have to render [i]n[/i] times in PRMan, I only have to render once in 3Delight.
What about [i]working[/i] subsurface scattering?
What about [i]fast[/i] ray-tracing (w/o writing your own ray-tracer)?
What about [i]machine-language compiled[/i] shaders (gives you an instant free 40%-60% speed boost on volume shaders)
What about a [i]network cache[/i] for RIB depedencies?
What about [i]proper control[/i] over hair dicing?
All this stuff isn't in PRMan but it is in 3Delight. And it doesn't make any difference. All that matters is that if either renderer has a feature that you desperately need and that one has but that the other hasn't, you need to buy a copy of the one that has.
What really matters is the features that you use 99% of the time to do your bread an butter work. And as far as these go, PRMan & 3Delight are identical if we're talking about VFX work.
about point based the point based occlusion and color bleeding have a lot more option in prman to control
What "control" do you mean?
3Delight can run gather() on point clouds. This means I can do anything I can express in SL to filter point clouds or use them for actual shading.
Not some black-box "ptfilter" uitility that has a lot more limitations than options (and there are a lot of options to ptfilter, indeed).
I could e.g. write a new subsurface shadeop in 3Delight in SL using this gather() on a point cloud. Try doing that in PRMan w/o writing your own DSO.
If you really think PRMan has more control over point clouds, you simply don't know enough about 3Delight (or probably most other RMan-compliant renderers) to make such a statement for starters.
, and the photon diffusion from point cloud is a unavailabled feature of 3delight, right?
I'm not sure what you mean by photon diffusion. [Donner's & Jensen's paper from last year](http://graphics.ucsd.edu/%7Ehenrik/papers/photon_diffusion/)? I can't find anything about this in the PRMan 13.5 docs.
maybe it’s because you use mainly the 3delight advantage in your production and not a custom pipeline who need lot of coding and DSO and this flexibility.
No, the company I work at these days uses solely PRMan.
one of our teammate worked before with 3delight and he was a big fan of it but now he prefer Prman too even if 3delight is a really great renderer
Well, maybe your friend doesn't know enough about 3Delight. :) These are quantitative arguments anyway "My ma knows someonw who says watching TV causes cancer". For every TD you know that "converted" (whatver that means) from 3Delight to PRMan, I can give you the names and email adresses of four people that liked 3Delight better even though (or because of) using PRMan since years. But this really says nothing about the quality of either product, so we should not descend to such ways arguing. ;)
for me it’s one of the best choice for a small production pipeline depend just on the need. if you want a deep API support Prman offer a lot of things that 3delight can’t do.
What "deep API"'s are you talking about? Rx? Rif? RSL plugins? They're all supported by 3Delight. These are the APIs most places use. Things that renderer X can't do? Check some of the header files that come with 3Delight. Not every API they support is documented and some stuff in there will not be in PRMan in the forseeable future.
Furthermore, if you use 3Delight and there is anything missing, just ask. When I used 3Delight in Australia at Rising Sun Pictures for two years, there was not single feature we asked for that wasn’t implemented by DNA straight away. The absolute longest we ever waited for a feature was seven days. That was btw. the RiNuCurve() implementation which we needed to render the spider webs coming from the custom web-solver RSP developed for “Charlotte’s Web”.
You don’t get this level of support from Pixar. No one does. So if 3Delight doesn’t have feature X or Y, it really isn’t that much of an issue. The addtion of features to 3Dedelight is entirely customer demand-driven. If you buy a bunch of seats of 3Delight and need a feature (or an API exposed), they will add it, you just have to ask. Consider that when you use arguments like “doesn’t have X or doesn’t have Y”.
Mind you: I’m not saying PRMan is a bad renderer, quite to the contrary. All I’m arguing against is that there is any adavtage of using it over 3Delight, quite to the contrary so.
To afford a honest opinion, you need to run actual production shots through both renderers. I don't know a single person apart from myself who is obseseed with the quality & capabilities of RMan-compliant renderers enough to do this -- particulalry using actual production shots. :)
And that is btw. the only reason I'm so outspoken about this subject matter.
I think if you truly took the time to evaluate 3Delight as an alternative to PRMan in your pipeline, you'd see that it is currently the better one.
Of course, it is always best to have both renderers, if you can afford that.