Proof of concept: Maxtor

#121

Crazy! I noticed PRMan was fairly slow when tracing in RfM, just wasn’t sure if I was doing something wrong. But that’s bloody good news. 3Delight is a third of the price too. Have DNA set a date for the 7 release?

#122

good thing for 3delight but he doesn’t offer the same potential as Prman, I hadn’t test the 7 beta but I will interested by If it’s so faster with raytracing? I’m curious to know how fast 3deligth is with GI and full occlusion on complex geometry. pRMan use point based technics for none raytrace using and you could isolate the raytracing only for reflexion. Is this possible to do that in 3deligth? because approx GI in prman 13.5 is really fast .
thx

#123 
    Personally, I think PRMan doesn't offer the same potential as 3Delight. At least not if you compare the current releases 3Delight 6.5.2x & PRMan 13.0.4. and work in feature film  creature VFX (which is what I do).
    3Delight has per-primitive display masks and it's subsurface scattering shits all over PRMan. Speed-, stability of integration- and pipeline-wise.
    The per-primitive display masks & exclusive displays allow me to get two dozen passes out of a single render that'd require me to render two dozen times in PRMan. The GI stuff is all fine on paper but only since it possible to use point-based it has become feasible to do a single bounce point-based "final gather" in most of the bigger facilities using PRMan at all. It all depends what you're working on...

3Delight can also compile shaders to machine language. If you do special effects, like e.g. volume shaders gcc/Intel/MSVC-compiled shaders will be up to 60% faster. 3Delight is also more stable than PRMan when one runs each renderer multi-threaded.
I think Pixar has been adding way too many features to their renderer lately in too short a period of time. Quality has suffered unfortunately. PRMan used do be absolutely rock solid.
Now I often finds it prints a more or less useful error message, then crashes. Mostly, one can fix the issue quickly by looking at the message. But this doesn’t change the fact that when you read the message the next morning, you don’t have renders on disk. 3Delight always renders, even if it can’t find a shader, can’t access a certain texture etc. The difference is that in the latter case I have something to show to my superviser/my client. In case of PRMan, all I have is a logfile of a crashed render. It all depeds what one’s priorities and preferences are, I guess…

I hadn’t test the 7 beta but I will interested by If it’s so faster with raytracing?

    Even 6.5 is up to 200% faster than PRMan with raw ray-tracing. What has improved in 7.0 is the subsurface speed (again, it [i]always[/i] used to be heaps faster than PRMan already).

I’m curious to know how fast 3deligth is with GI and full occlusion on complex geometry. pRMan use point based technics for none raytrace using and you could isolate the raytracing only for reflexion. Is this possible to do that in 3deligth? because approx GI in prman 13.5 is really fast.

    Yes, 7.0 will have point-based GI as well (which includes amb. occlusion).
    The beta I have is already almost as fast at PRMan and this is the very first beta with this stuff... :)
  
    .mm
#124

If possible, can you very briefly elaborate on this in relation to render passes?

#125 
       Sure. When you render to AOVs, say object A writes to AOV X and object B writes to AOV Y. If they overlap on the image plane, they will always matte each other.
       I.e. if object B is behind A and they overlap, A will cut out (matte) B. If you compose them over each other, you get the correct image. No problem there.
       
       However, if you want to do some advanced compositing convolving A & B in some fancy ways (think e.g. of blurring B), you can't do this properly anymore, because B was cut off by A -- i.e. there's no information for the blur filter to pick up in AOV Y to do the right thing.
       In such a case, you need to render twice so you can get Y w/o being matted by A -- in PRMan (and basically any other renderer I used so far).
       Not in 3Delight. You just declare the display as "exclusive".
       Another problem with AOVs is that they don't carry their own opacity information. They rely on Oi (the primary display's alpha channel).
       But if you render objects "exclusivey", this doesn't work anymore (it also often doesn't work well w/o "exclusive" coming into play, but that's a different topic). Hence 3Delight has "caculatealpha" which gives you the exact coverag of an AOV added as an extra channel.
       
       This is the simple version. For more advanced stuff, forget "exclusive". Think about trace membership groups. They determine which rays can 'see' an object and which can't. Now if you treat the camera as a ray-shooting entity, you can allow objects to be visible in an AOV depending on which trace group they're in. 

Display "foo1.exr" "exr" "color myFancyColor"
  "string subset" [ "sphere1" ]
Display "foo2.exr" "exr" "color myFancyColor"
  "string subset" [ "-sphere1" ]
...
Sphere 1 -1 1 360
Attribute "grouping" "membership" [ "sphere1" ]
Sphere 1 -1 1 360

       Since each primtive can -- in theory -- be in it's own trace group, this allows you to attach a shader, that writes to a certain AOV, to a bunch of objects, yet get that AOV out seperately for each object from a single render (see above example). And best of all, since this is done through displays (or display channels even), you don't have to recompile shaders or add new AOVs to them to get a completely re-configured set of passes from a single render that will make your comper happy. :)
       
       Imho, this is the single most powerful feature added to a renderer in recent years. From a VFX production perspective. It vastly simplifies the pipeline, allows to bring down network traffic (RIB is only read once); RIB pre-processing-, render-, shader writer- and general planning time are reduced considerably.
       My very personal pov of course, but I used 3Delight with this feature on two shows... When they added this feature it felt a bit like using PRMan for the first time 11 years back. I never looked back then...
       
       You will find a lot of these things in 3Delight. Small but powerful innovations (not "loud" fancy features) that make a real difference in production...
       
       Cheers,
       
       Moritz
#126

Thank you! I really appreciate the thorough response and am especially excited about the following:

“Hence 3Delight has “calculatealpha” which gives you the exact coverag of an AOV added as an extra channel.”

#127

thx mauritus for all precision about 3delight, I don’t know really well this engine but it’s seems to be really cool. I will test the 7.0 version for sure , do you know when it will be released?

the beautifull things is 3delight is free for the first license and I love that policy.

nice news about all that .

#128

Ok, new features:

We now have string substitution in MaxToR:

In most places you can enter strings (RIBBoxes/AOVs mainly), the following strings will be substituted:

[ul]
[li]$F = The non-padded frame number. E.g. 5[/li][li]$PF = The padded frame number. E.g. 00005[/li][li]$IMG = The main image file name (respecting the “Append frame number” option). E.g. image_00005.tif[/li][li]$RIB = The rib output path (“Base Dir” in the render globals)[/li][li]$OBJ = The current node’s name. E.g. Sphere01[/li][/ul]This allows for greater pipeline flexibility in that you can use RIBs generated by third-party means with MaxToR by passing them in a RIBBox.

For example, let’s say you have your own hair generator tool that can output a RIB archive, and it generates ribs of the form “hair_00001.rib”, “hair_00002.rib”, etc. You can add a RIBBox modifier to your creature passing

ReadArchive "hair_$PF.rib"

in the appropriate box, and it will attach the hair to your creature at export time, and you will render with hair/fur!

#129

Releases come every 6 months. The last one was in February, so 7.0 should be out around August/September. See Wikipedia.

.mm

#130

Sneak peak at what’s coming soon in MaxToR:

#131

Great News the MaxtorMaterial
Its looking very similar to the GelatoMaxMaterial, you know the Amaretto conection?
maybe you can get some usefull ideas from Amaretto its becoming a solid bridge betwen Max and Gelato, the non strong could be the Gelato material its not very artist friendly

#132

Will the parameters reflect what is in the shaders (for custom shader) or will it be a “standard” shader.

#133

You load a shader, and it procedurally generates a UI with all the shader’s parameters allowing you to tweak and preview them on that swatch, similar to how Liquid works.

This will save you from typing them by hand in the MaxToR_Shaders modifer, and will eventually replace it.

#134

Ok, new video:

http://www.savefile.com/files/881335

#135

Cool, it’s just what I need.

#136 
Then I hope you'll enjoy playing with it :)

[b]New version released![/b]

- Many bug fixes.
- New [b]MaxToR material[/b]. This allows you to interactively tweak and preview shaders and assign them to objects via the material editor. The old Shader modifier still remains, but the material will take precedence over it.

[b]Important notes:[/b]
It only works with 3Delight so far, and only version 6.5 was tested.
You need to get the updated 3DL shader pack along with the new maxtor.zip archive from the website.

Before you try to preview the shaders, make sure all the shaders can be found by setting the appropriate "Shader path" under "Additional Paths" in the render globals.

When you pick the shader in the material, make sure you pick the compiled .sdl file, not the shader source.

It supports float, color, and string input parameters so far. They are the most common parameters to surface/displacement shaders, I don't think point, etc are used that often.

However it handles unsupported parameters gracefully, by ignoring them. So if you get any errors, its probably a bug.
And if you are using arrays (as parameters), you’ll probably have to use the good ol’ shader modifier instead. That’s the price you pay for flexibility :slight_smile:

Available at the [website](http://four.fsphost.com/scorp007).

EDIT: Hold up, I’m re-uploading, so if you get a corrupted download, please do it again in 5 minutes.
EDIT2: ok, its good to go… Now!

#137

I can’t wait to try this! The new material looks great. If possible, I would suggest at some point including idiot-proof Render Element output.

#138

Funny you’d mention that, MaxToR has had AOV (Arbitrary output variables) support for a while :slight_smile: Have a look at the manual on MultiPass Rendering, or the video at the website.

EDIT: Hmm. Just realised I introduced a bug into the material system. Worked before. Time to resolve it…

#139

Brilliant! You are way ahead of me. I should have RTFM more closely :).

#140

Ok, version 2 of the MaxToR material has been released. It should now be a lot more stable to work with. It properly handles multiple materials and saves and restores them with the scene.

Have a try with the new one.

EDIT: fixed another little bug, so you might want to redownload it, if you have an older version.
EDIT2: Oops, another little change, not really a bug, I just accidently limited the float input to positive numbers only. This is now fixed. (It now allows signed inputs.)
EDIT3: Another bug fix. I recommend you get this.