renderman on xsi

[StefanA]

no

[okno]

so renderman is only for maya?

[okno]

and some other render tool?

[marci2001]

it's a question of your programming skill

(and of course purchasing renderman, wich is not a cheap bunny)

M

[okno]

and can i use renderman or not

[ThE_JacO]

if you are really good at your stuff you could write something wich will convert MI files (and eventually a .xsi complement to those files) into rib files.
you'd also need to implement some sort of frontend to this conversion inside XSI...

good luck if you ever go that way, it's a one way trip to hell :)

if you can't go that route wait till somebody completese the xsi2rib stuff wich is WIP since a while now, or export from XSI to SI|3D (where you can use AL's Softman).

P.S. renderman isn't only for maya, it's just a matter of outputting a rib file from whatever application you need, whatever this is done natively by the app or by a 3rd party product.

may I ask why you'd want to get into renderman ?
Is it simply because of the film hype or you actually have an interest in wetting your toes in the SLIM waters ?

[Daolohua CnC]

(removed)

see above

[okno]

Yes i can render in renderman.

thanks to google.com
:-)

[Atyss]

Originally posted by okno
thanks to google.com

What do you mean?

[Sanguis Mortuum]

http://www.animallogic.com/research/softman/

[okno]

but softman is only for softimage 3d :-(

[frumpy_bunyin]

Renderman is a stand alone renderer.
You use it by generating rib files which it renders. To generate ribs you need a package that supports them, ie houdini. Or a plug-in for others, Mayaman, MTOR, maxman, softman.
Since at this point you're just spitting out geo, lights and shaders to the renderer you can get there via a few routes. Like exporting geo from one package to anohter where lighting and shaders are set up and then ribs generated and sent to prMan.

FB

[ThirdEye]

In all honesty is there a precise reason you wanna use renderman for? Is it something that Mray isn't capable of? :shrug:

[okno]

No mental is nice
i only would like to try renderman. (for fast and better nurbs render)

[wurp]

Originally posted by ThirdEye_01
In all honesty is there a precise reason you wanna use renderman for? Is it something that Mray isn't capable of? :shrug:


Thats all wrong, going through all the work to be able to render in prman from within xsi just for better nurbs is just dumb, specially since XSI's nurbs toolset isnt that great anyway...

What exactly are you after? To me it seems more like you dont really know what prman is and just want to use it for its coolness factor?

just my 2 cents

[bjoo]

What mentalray lacks when it compared to prman is..

1. Deep shadow
2. Risk free motion blur and displacement.
3. Anti-aliasing capability
4. Blobby and constructive solid primitive
5. Better network rendering capability
6. Handy shader writing (In my case)
7. Full length feature experience

Bjoo :)

[marci2001]

what's deep shadow?

thanks

M

[fey]

Originally posted by bjoo
What mentalray lacks when it compared to prman is..

1. Deep shadow
2. Risk free motion blur and displacement.
3. Anti-aliasing capability
4. Blobby and constructive solid primitive
5. Better network rendering capability
6. Handy shader writing (In my case)
7. Full length feature experience

Bjoo :)


Hi bjoo,

Could you elaborate on some of the points?

3. What do you miss in MRs Anti-Aliasing capabilitys? I never heard anyone complaining about it.

4. Sounds interesting. What do you do with it? Is it much better than MRs primitives?

5. Why has it better networking?

6. Again, I never heard anyone complaining about this. In fact Programmers seem to think it´s very well laid out. Whats wrong with it?



thanks,

fey

[fey]

interesting discussion:

Originally posted by gga
Sorry. I had to comment, since a lot of misconceptions and just plain wrong information was being discussed about mental ray.
I work at ILM where we daily use both prman and mray and I personally have about 5 years of experience with each package, as both an user, and developer writing shaders... and can tell you stories of pulling my hair with both
This is sort of a list of good and bad points of each renderer.

1) mental ray is a hybrid renderer. As a matter of fact, it has been such since v2.0. A hybrid renderer is new to prman, but it is NOT new to graphics community. Besides mray... lightwave, maya, etc. are all hybrid renderers and have been so for quite some time.
This means that indeed you can use the package only on scanline mode if no tracing is required. Most good hybrid renderers like mental ray, prman and lightwave, can mix rendering scanline with raytracing within samples, even. Bad ones can't or have horrible limitations (maya comes to mind).

2) mental ray3 IS a micropolygon renderer, which is not based on a reyes architecture. The talk of not being able to do driven displacements thru the hypershade is just bogus.
mray is a micropolygon renderer that it is based on an object caching architecture (this is both good and bad). Instead of splitting objects per buckets, objects are split into subobjects (think of doing dicing in screen space vs. world space, I guess). The quality of displacement mapping has little or nothing to envy prman anymore. The object caching is also less subject to patch cracks as prman is. mray, unlike prman, tries to always maximize the memory consumption and keep as many triangles in memory as possible when raytracing (ie. the caching is less agressive). This is not bad, it makes the renderer faster during traces, but yes, when you fire a mray render without specifying memory limits, you will immediately see it try to take over as much memory. Acceleration of raytracing is done by hierarchical grids or bsp, albeit bsp is still the preferred approach.
mray3.1 was the first implementation of this and it did suffer from some bsp creation problems which would spike memory like crazy albeit was usuable already for most projects. mray3.2 beta (not yet released) has addressed most of the issues and solidified the architecture more. Currently, I can already testify that the object-cache architecture is already proving to be as successful as prman's reyes ones in many scenes, more so when raytracing is involved. Still, raytracing of micropolygons IS expensive compared to just scanline rendering or to raytracing objects with good but not micropolygon tesselation. mray still provides the best (read fastest) implementation of this I have ever tried. Over the Christmas break, I raytraced scenes of over 10,000,000 polygons with little issue and under 2.5hs. Still, as we throw more and more complex cases, we do find bugs and issues and we usually report to both vendors as problems they need to address. For example, I recently did find an obscure bug with the caching being flushed too much leading mray to technically render 150,000,000 ( yes, that's 120 million triangles) due to re-tesselation. What surprised me was that as ugly bug this was, the architecture handled it and albeit it took long (16 hrs), it worked just fine. And 16hrs for 120million triangles sounds REALLY cheap to me, actually --- specially considering the code doing most of the re-tesselation was mine and not optimized, and not as good as mray's tesselation code

3) subdivision surfaces. mental ray provides a very comprehensive subdivision surfaces package which is sold as an add-on shader library. It is a silly marketing decision. As such, indeed most translators do not support it. Also, regarding its being sold in the USA, not sure if it could expose mray to legal action by pixar, since pixar holds some rather obvious patents on subdivision surfaces.
The subdivision kit is more complete in terms of subdivision types and in terms of hierarchical subdivision than prman is, but it does not resolve subd's to bsplines as in prman implementation.

4) mental ray's architecture has proven time and again to be MORE flexible than prman's, not less. We usually try to do everything with prman when possible since our pipeline is built with it more in mind and due to having been used at ilm for so long, we also have many more artists familiar with it. But albeit SL is nice and friendly, prman's lack of openness bites us whenever you want to do anything BEYOND SL. Technically, we do have ways (technically and legally) to hack into prman code. However, we have very few people who can do so (technically and legally) and many times we don't have the time. And prman's DSO architecture is simply not mature enough. mental ray suffers from none of that (basically, anyone that can code C can be writing mray shaders in no time and the API is way more ope). As such, when prman fails or is not good at a certain thing, mray usually ends up being used as a complement ( raytracing, blobbies, atmospherics, etc).

5) mental ray's scanline rendering is actually FASTER than prman. Yes, you won't hear this very often, but it is true. Now, this does not mean the renderer is faster, thou ;) Let me explain:

mental ray's scanline renderer is on average about 3 times faster than prman10 and ~1.5 than prman11, when equivalent shaders are used for your average ilm creature (say, our superduper plastic shaders with million of knobs). This is so for preview renders without motion blur.
What DOES make prman amazingly fast during scanline renders is this great fact:

When motion blur is on, performance hit for any prman render is (usually) less than 50% of what it was without.

NO renderer on the market is even close yet to offer this... I know, we usually try them all.
With mental ray (and most other renderers), motion blur implies about a rather constant 500% increase in render times at least. This usually offsets ANY benefits of the mray scanline renderer when motion blur is on. Many places only turn on motion blur for final renders. Not so at ilm. EVERY one of our renders is motion blurred. Usually our supervisors require it. Kind of silly, perhaps. But certainly doable for prman and it is the one feature that makes prman worth its price tag, in my opinion.
And yes, you can do tricks like 2D motion blur to compensate... they just don't look as good, that's the problem.
Now, that's for scanline rendering.
For straight raytracing... prman is 5 to 10 slower than mray. No suprise there. After all, this is Pixar's first implementation of raytracing. It is likely to get better with newer versions.
With raytracing and motion blur on ... well, no miracles here. We usually try not to since it is usually too expensive with any renderer. However, mental ray is still better. As slow as it is, prman is (and I'll be nicely optimistic here ;) 5 to 10 times slower, without even mentioning the other issues about it.
For global illumination ( final gather / caustics ), mray is slightly ahead in most aspects while prman is ahead on at least one. However, speed and quality are relatively comparable and the differences will hardly make any difference to your average user: mray supports caustics and volume irradiance while prman has a more flexible api to work with irradiance caches in shaders.

prman is king in terms of primitives ( mray lacks CSG, built-in blobbies, sphere primitives, no point primitive, etc. and mray's hair is very new and not production proven ). mray's only strength here is support for high order curves and surfaces (as those used in CAD and engineering).

mental ray's basic shadow mapping support is now much cheaper than prman since they can be created on the fly at any resolution with little performance hit. On prman, a separate pass is always required. Prman now supports deep shadow maps which are great for volume effects and more so for hair. mental ray shadow maps are not yet deep shadow maps, meaning hair shadows are still better raytraced right now.

Prman's atmospheric shaders are slow at best and not too great. mental ray shines in this allowing you to create anything from blobbies shaders to very fast raymarchers. The latter package also has some internal handling of in/out volumes to allow intercrossing and travelling thru volumes.

Prman allows stitching of subds to handle displacement without cracks. Note however, that this is only for subd's not for generic patches. mental ray has stitching for patches, but they do not work for displacement.

RIB format is slightly more compact than mray's .mi2 format, but MUCH harder to debug and read, since it is ALL binary, unlike mi2 which is a hybrid format. RIBs are also more compact if you spit them in a hierarchical fashion, making them even harder to read and debug.
RIBs were originally a standard that did not catch on mainly due to Pixar still keeping hold on the copyright and licensing of it. However, in the past few years, other renderers have indeed started using the RIB as an input mechanism. This is both good and bad. It means the standard has already deviated but it also means that if you'd like NOT to use prman, you can switch to other competing products much more easily than before.

mental ray's format is as much a standard as prman's rib is, albeit no other renderer uses it yet as input. It supports shader networks, user data, and geometry instancing which ribs do not. More important, it supports progressive scene changes, for IPR functionality. It also does NOT work hierarchically, which is a big relief.
RIBS parameter passing and attachment of variables to geometry is VERY elegant, and although the same can be done in mray, it is not as nice. Only phenomena is elegant in mray.

PRman works with a SIMD architecture while mray does not. This is the other BIG plus for prman. This allows prman to calculate derivatives for antialiasing shaders trivially, while in mray, the shaderwriter has to do more work for that.
Now, however, that raytracing is introduced in prman11, the benefit of prman SIMD becomes less, since afaik, neither renderer does derivatives calculations beyond the first ray hit (could be wrong about prman, need to recheck the latest one). The only package on the market that was superior in this aspect was the now defunct Entropy, which did allow them.

In terms of documentation, mray's documentation is and has always been poor at best, lacking examples. Prman documentation while far from being great is full of examples and the new application notes for raytracing are simply outstanding.
For both renderers, however, it is still recommended to get the publication books sold.

mental ray integrates seamlessly with a number of products on the market with more or less successful interfaces -- usually more tighly built around the package workflow. Currently 3DMax, Houdini, Maya, Softimage and XSI support it.
Prman's main translator is the one that comes with RAT (irma/mtor/slim combo). Houdini support is native. For max, you need something like MaxMan and for Soft, softman. There's also some very ugly lightwave support. For xsi, there's no option to spit out ribs.

Prman's stability is simply legendary and is no overstatement saying than some of the best programmers in the world have contributed to it. Simply put: what other software product can you say has lasted for over 20 years with little core modifications? When Pixar releases a new feature, it has usually gone thru about a year of testing internally, and it shows. Hard to find bugs in prman.
mental ray's reputation is shaky at best in this area. Many users tried pushing mray to do things it was never meant to do in its old times and to this day, mray still lacks that internal testing that it is so important. As such, whenever mray introduces a new feature, my guideline is to stay away from it until the following revision of the software.

In summary, if you can afford both, do so. Then you should learn what they are good for and not try to use a hammer when a screwdriver is better.
If you can afford one, look at the list of good/bad features above and choose. Yes... something, somewhere will not be possible or be as good or easy to do. Just know what that something is, and avoid doing projects that require that (or find creative cheats).

Finally, if not convinced with comments, try them yourself. Both Pixar and mental images offer demo versions of their products.

[elvis75k]

Amen

[Atyss]

Originally posted by bjoo
What mentalray lacks when it compared to prman is..

1. Deep shadow
2. Risk free motion blur and displacement.
3. Anti-aliasing capability
4. Blobby and constructive solid primitive
5. Better network rendering capability
6. Handy shader writing (In my case)
7. Full length feature experience

Bjoo :)


Anti-aliasing capabilities? You got to be kidding dude.

Better network rendering capabilities? Have you ever looked at Rendering With Mental Ray?

Full length feature experience? Okay, granted, not as much as PRman, but mental ray DOES have full length feature experience.



Cheers
Bernard

[qba3d]

So is there a technological problem with mental rays motion blur??
Well I actually love mr - an tried renderman - love that one too..
what i found is :
1) Renderman has a strange texture sensitivity - it shows every color difference of texture - while mr flatens them a bit... but it can be tuned using a post proces - like saturation +10% and here you have it..
2) MR is extremally fast exept for three aspects:
-Hair - at ;east in xsi- rendering hair in renderman is a peac of cake - if only you dont use mb:)))
-Motion blur- drama - iven in xsi 3.5 - with rapid motion blur - it is still far to slow some times it is useless
-DOF - you have to use a post dof usinf Z map - while in renderman you have a lovely DOF without a render time going crazy..

Here is my question:
first- isn`t there a way to create a good quality post proces motion blur? like maya`s 2d motion blur?
well it is not us good us rendermans but it is enough for most jobs
second - there must be some technical problem - or some architecture isue in MR - because in v 3.2 they still cannot speed up a motion blur...
any GURU clould answer?
Q.

[wurp]

The reason ANY raytracer will be slower on DOF and Mblur than prman is because prman is a REYES renderer. Basically prman will store as little of the scene in memory as possible when rendering, it'll only store whats being rendered in memory, after its done with one part of the rendering it'll throw away the memory it allocated. Mental ray on the other hand will throw in all of the scene in a BSP acceleration tree, I dont know exactly why but this is way more efficient when doing raytracing, but it'll slow down a lot while doing for example DOF.

Im not an expert in this area, but I think its quite safe to say that both renderers are targeted at different areas, there are simply situations when prman will do a better job than mental ray, and vice versa.

[ggg]

this apparently does rib to mi.
from francesca on xsibase:
http://www.dctsystems.freeserve.co.uk/ethel.html
I thought I recalled seeing an mi2 2 rib somewhere too, anyone here?

[capin_crunch]

Originally posted by okno
Yes i can render in renderman.

thanks to google.com
:-)

You didn't know that google had a built-in RIB exporter for xsi geometry and scene fiiles :p

cheers
-capin_crunch

[Dan Wade]

http://www.alamaison.fr/3d/lm_2DMV/lm_2DMV.htm

If you want a solution to motion blur in XSI/mentay ray, check this baby out. It is post, but it does a pretty fine job of things.

Basicaly, you just need to render out a special pass of your frames. This plug extracts any and all motion vectors from the objects in the scene. The more they move, the more they give off. And because you can render them out in SGI format (16 bit), it can save 60k + of information per frame.

It works a treate. u can have deformation on objects, everything basicaly. And even though you have to render twice as many frames out (original pass without motion blur and a motion vector pass), it still takes a fraction of the time than it would rendering a single pass with MR motion blur on.

Cheers,
Dan.

[ggg]

thats' pretty cool if you have smooth kit and combustion otherwise you'll have to make your own filter or use another that can process the rgb as vector and intensity info.

don't have 3.5 yet but haven't they added support for motion vectors in fxtree yet :(

[Milho]

It's a pitty that there isn't a RIB exporter for XSI.
It's not even a question of what MR is capable of but more what you prefer, or what you are interested in.

E.g. there are many commercial and uncommercial renderers based on the renderman interface and it would be cool to have them working with XSI.

Wish I had more experience and time to write at least a basic rib exporter.

Maybe there is hope, I read about this RiO on edharris.com linkpage, but it seems the sourceforge project never started.

It just amazes me that such a big app with such a big community didn't bring up something for it yet.

Let's wait and see what happenes... :)

[CGTalk Moderation]

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.