The loader seems to pass to the renderer ONLY the display representation of the xmesh.
In other words, point and bBox mode render empty (but QUICK! ^^), faces passes the (decimated!) face description.
Regardless of the render dropdown.
So atm it is necessary to ViewPort load the whole mesh to get it to render (bummer!).
I’ll attach a wish too: the ability to FIRST set the display options (point, bbox, decimated faces), and THEN load the xmesh.
Atm canceling the load dialog doesn’t create the xmesh.
All it’d need was to go ahead and create an empty loader, so the user could change parameters, and then load the mesh.
Now the behavior slightly changed:
The loader first loads the full xMesh to viewport (that’s likely undesireable, if it was off in the first place), and then passes that to the renderer.
Better than before when nothing was getting renderered at all, i guess, but still not quite ideal…
Out of curiosity, does it behave the same when you render in Maya Software or mr?
AFAIK, there are some pre-render scripts involved in switching states, I wonder whether VRay behaves differently…
Could you please open the Render Settings dialog (Window menu -> Rendering Editors -> Render Settings). In the Render Settings dialog, switch to the “VRay Common” tab, and open the “MEL/Python callbacks” group. What do you see under “Pre Render MEL” and “Post Render MEL”?
When I switch to XMesh tab and create an XMesh Loader using the icon, I can see two scripts appearing automatically in the Pre-Render and Post-Render script fields of the Render dialog. So the question is not whether you added anything, but whether VRay or something else removed them…
Of course you were right Bobo.
Removing the code just renders the VP representation.
I already bugged Vlado offering him your skype contact: it’d be great if you guys got in touch and made the maya version as elegant and performing as the max one.
It works, as it is, but it leaves the flank well open to alembic for deferred loading (working in vray 3.0 beta), and i would really like to do without that.
I’m curious, what issues have you noticed in the Maya version, compared to the Max one?
I’m wondering why those Pre-Render and Post-Render scripts were missing from your scene. How did you create the XMesh Loader in your scene? Did you use the Load button in the XMesh shelf?
Well, for one, in max and vray there is no need to preload the whole mesh description for it to render: it loads as the render process starts, but not in viewport, and can be set to dynamic, hence swappable out of ram if not needed anymore.
Second, the xmeshes in max automatically swap out the original geo for the xmesh loader, and there are much better (in the little details that make up usability) ancillary tools: the saver, with versioning support (automatic version up to the latest), the sequence editor script, the ability to create nodes first, and fill them in after the load/display options have been set, and so on.
On the maya side, although fairly expectable, everything looks fairly scant, by comparison, wanting for more ancillary tools to be developed (either on our, or your side, really. it makes no real difference).
Vray 3.0 has deferred loading of alembic caches, including point and hair primitives.
Compare to being forced to load the whole mesh description in VP to render it, and you see why I am asking for a tighter integration (seriously, that’s a nono, which kind of defeats the purpose of having all other representations available for VP preview!).
I’m not the one deciding, i’m the one trying to make a good case for the adoption of xMeshes, and i can see the case being a lot more easily, and convincingly, made on the max side, right now.
To get the script lines in the render settings, create a new scene, switch to vray, create a loader with the “LOAD” icon from the toolbar.
Vlado didn’t get back to me today, but do feel free to contact him directly at vlado[at]chaosgroup.com
Max was designed to provide two representations of geometry. It has an internal Render mode that is triggered when the renderer is fired up. All modifiers have a Enable in Viewport/Render icon, and many other objects support Viewport vs. Render settings (TurboSmooth iterations, Particle Flow particle count and meshing and so on).
On the Maya side, for both XMesh and Frost, we had to emulate the same behavior without the benefit of a built-in viewport/render system. (heck, Maya doesn’t even have the concept of internal time context and you have to move the time slider with the hope that all DAG nodes will be updated as they should). So the scripts we are adding as Pre/Post callbacks are supposed to do what Max does natively. Unless we are missing something - any Maya gurus here?
We are not developing specifically for VRay, we are developing for Maya. IF we decided to do tighter integration with VRay 3.0, it would have to happen on both Max and Maya’s side. I believe we had some previous experience from the Frantic days, but I am not sure about the exact details…
I agree with your other post - creating an XMesh Loader should be decoupled from the actual picking of the file. If you cancel the picker, the Loader should still be made, so you can tweak the settings and then pick a sequence. I will see if adding an automatic version numbering mechanism would be trivial (I hope so). As for the other tools, it will take some time…
Those are likely the reasons why VRay in Maya has to do a lot of doodling work before the render actually starts getting fed data from the host app.
Unfortunately, as you know, Bobo, i’m no maya guru either, but I do have a couple of good one in the office, i’ll ask them.
This week we should get Maya 2014 rolled out, so i’ll be able to report on any substantial operative difference with Alembic, and hopefully finally commit to a choice…
Thanks ever so much for all the explanations and time taken so far!
Lele
P.S.: yeah, i distinctly remember Conrad optimising the vray tracing of xmeshes, and using the before and after versions with a big grin on my face, but that was for max.
Well, all I can say to alembic is “lol”.
Both performance and implementation are a good order of magnitude (performance nearly two…) worse than xMeshes for Maya can offer in their current state (which i have no doubt is not ideal yet, so it’ll only get better), and even without the lovely support from you guys at Thinkbox would make the choice a no-brainer…
I suppose my case is made, will surely contact you soon enough for the ancillary stuff (like buying the licenses, ya know. ).
Thanks so much for now!
p.p.s.: yeah, i know, Bobo, it’s wasn’t Mike, as i remember, it was Conrad doing the optimisation. Can’t remember why.
).