Proof of concept: Maxtor


EDIT: This post is horribly out of date :slight_smile:

Hi guys,

   Just wanted to share a little project I am developing. Please, [b]don't hold your breath[/b], this is far from ready for general consumption, there are still countless vital issues to resolve before it's ready for production use. I am the only developer, and I doing this as a hobby, so don't expect a complete product any time soon. I may occasionally share updates, but nothing is promised yet.
   Maxtor is a pure C++ bridge from 3ds max to Renderman. It is designed in a way such that it will be easy to port to various Renderman complying renderers. Currently I'm using only 3Delight, but I intend to support Aqsis, and some others eventually.
   Essentially, what I am aiming for this product is something similar to RfM. I want the user to be able to create a scene, hit render, and (on a basic level) the result should look exactly how the Default Scanline renderer looks. (This involves creating custom renderman shaders to mimick exactly how max's lights, shaders behave.)
   So here is a scene with 10,000 teapots, a total of 10.2 million polygons, exported and rendered in 7:25 minutes. This is using catmull-rom pixel filtering. Please remember my plugin is in [b]very [/b]early stages.
   I am sorry but the images are somewhat large.
  Here is the full render:

Here is an older rendering, 2 minutes (crappy Box filtering)
 On a side note, I actually have a fairly complete scripted plugin I wrote a while back, but never released to the public. But it's no longer being actively maintained. It's decent if you want to play around (It does support all 3 types of motion blur, uses DRAs, renderer independent, and more, though). But you guys probably don't want it... (Read: I don't have time to support you, should you have problems).
 So this is basically the successor to it. I'll probably post some simpler scenes/examples later, showcasing how close it compares to the default renderer, for basic scenes (lighting, etc), if I find the time.


Interesing approach.
I don’t know renderman and I missed the bmrt.
The cool thing about maxtor is that it renders so much polygons?



Hey this looks really interesting!

keep it up.

Just one idea, I’d consider changing the name to something that wouldn’t steer you into copyright problems :slight_smile:


rdg, Keep in mind that renderman was never designed to be a polygon renderer. I’m just happy that it can render so much nowadays. Also, note that in a real scenario you probably wouldn’t need so many polygons anyway, as most meshes you render (e.g. a character) would be in its base cage form, and sent as a Subdivision surface to be smoothed at render time.
On top of that, you would use a displacement shader to get any level of fine details you may need.

lehmi, heh, I did think about the hard disk manufacturer, but I don’t know that my product is related closely enough to warrant any legal issues. If it does, I will change the name.

Due to some interest in my maxscript, I have decided to post it here for everyone to play around with. (This is not the C++ plugin)


suwheeet! good work man… can’t wait to try it out. If maxtor does give you any crap just call it maxtorm :slight_smile:


I had some (presumably) threading issues with the C++ version of the plugin, so I decided to (significantly) improve the scripted one. Well, it’s not longer purely scripted, it has some C++ backbones to it.

Thought I'd post a video showcasing some basics... (5 MB)


And here's a picture (Rendered in Aqsis):



Ooooo or even simplify it further:

Xtorm because everything is better when spelled phonetically using Xs :smiley:


Wish I knew what all this meant, Im such a render noob lol. But I don’t use Renderman anywho, but I wish it the best of luck.


Yeah, not sure about the name, might have to change it, but that shouldn’t be too much of an issue.

For those who don’t know: Renderman is an interface specification created by Pixar (I’m sure you all know who they are ;)). They also wrote the first implementation of this standard called PRMan, which you can buy for $3500 USD. Of course there are free, open source alternatives (Aqsis, Pixie) which aren’t as good yet (in terms of speed, quality, robustness), but are being developed actively.

Now, the thing is, you could go ahead and download Aqsis, or Pixie, but how would you render your scene you built in 3ds max with it? Or you want a whole animation perhaps?
Well, you would need to feed Aqsis/PRMan something that it understands, which happens to be a scene description as described by the Renderman interface (Either in C, or the ASCII binding: RIB). Of course doing this by hand would be next to impossible (Imagine specifying each point position, normal, u, v, coordinate of a teapot in a text editor).

So this is exactly what my plugin is trying to solve: make a bridge between 3ds max and Renderman.

For Maya there exists MtoR, which comes as part of the RAT (Renderman Artist Tools) collection from Pixar. So you can kind of compare it to that.
It’s more flexible than RfM, as you can directly output RIB’s for distribution across your renderfarm, albeit it doesn’t convert max shaders to renderman natively yet. But that wasn’t my goal really, its aimed as a TD tool, like MtoR, where it’s assumed you’ll be writing your own renderman shaders.


Here’s a quick test, rendered in 3Delight, 10x10 pixels samples, DoF, shadows:


Here’s why renderman is superior to your typical renderers: True Subdivision surfaces!

Notice the richness of the 3delight rendering over what max scanline provides (Observe the polygon silhouette in the Max rendering).

Also, look how easy it is to get an accurate renderman translation of a max scene at the click of a button. And if you need the flexibility in a pipeline, it’s all there. I’ll post up the modifiers sometime.



Great job! I’m always interested in experimenting with new renderers.

Would it be possible for you to include render times with the examples your posting? I’d love to see how long it took to render the images you’ve already posted, and any future images you might create.

Thanks in advance


Sure, will post render times on any future images.

The thing is though, this differs vastly from renderer to renderer. For example 3Delight will be bloody fast, wheras Aqsis and Pixie won’t. I haven’t got PRMan to play with, but I’m sure its at least as fast as 3delight.


No problem. Render times weren’t ment to prove anything, more about getting a general feel for it.


Sure. Well I hope this video will give you a little feel for the speed. I’m running a modest single P4, 2.6 Ghz, with only 512 MB ram. And there’s the video capture software to take into account…

New video for all.


The video was very cool, thanks for taking the time to make it.


Glad you liked it.

I’ll keep improving it as I find weaknesses and keep you guys updated. The videos haven’t been very extensive yet in that they haven’t showed a lot of functionality MaxToR is capable of (RIBBox’s for one), but mainly focussing on the usability side of things.

I’ll keep you posted.


Awesome man, i always wondered why we didn´t have in max a proper way to render to renderman! and now i see that is possible! keep posting mate!


Thanks metamesh.

I have been working to get proper instancing working. So now, if you have 10,000 teapots in the scene, instead of exporting the same teapot 10,000 times, it exports it only once, and instantiates it 10,000 times. So we only have 1 DRA (Delayed ReadArchive) per set of instances. For a scripted tool, it runs pretty quick, at 16 secs to export a scene this big. Most of the time is spent on determining whether an object is an instance or not. I might be able to optimize it a bit more, but the important thing is that it scales linearly. ( O(N) )

Now I just need to implement LoD. That should cut rendering times substantially.


W00T! I now have Level of Detail working fairly well.

Here’s an extreme example to demonstrate that it works:

Notice how the teapots transition smoothly into spheres as the objects take up less screen space. Of course in reality, the size would be far smaller before they degrade to spheres. I have made that attribute available to the user (Relative Detail), which translates directly to the renderman interface call of the same name. Here it is set to 0.01, which implies the rendered scene is 100 times more crude than it ought to be. The default, and “normal” setting is 1. That way the teapots (or characters) will only degrade when they take up a sensibly small amount of screen space.

I actually have them degrade even more into a single RiPoint when they take up even less space, so processing very far away objects is lightning fast. Great for huge armies :slight_smile: