[JDHill]

I simply don't have a definitive answer for you at this point, but it does look as though it will be fixed in the next build. I am not trying to be evasive, I just don't like making authoritative statements when I don't personally control all of the code involved.

[brodie_geers]

No problem, that works for me. I'm glad that we're on the right track with it at least now.

-Brodie

[Richard]

Yeah I get the same issue. I found if I open the export in Studio then delete each object one by one going up the object list it will eventually export. Then I can go back to SU and explode the offending object and re-export all and it will then render fine from Studio. Well for that issue anyway! Then I have to go through a bunch of other explodes to get all faces to render from Studio.

[Half Life]

Here's a free Ruby that will explode everything -- using it before export may temporarily solve the issue.

http://www.smustard.com/script/Bomb

Best,
Jason.

[Richard]

Thanks mate, yeah have had that script for a while though don't really want to explode all as I'm counting on lots of instances now they work like a treat!

@JD

Mate I did some testing on the section of the model that was causing this issue and seems it could be caused by the flipping of a nested component. In this case the room was flipped and then I went back in and re-flipped the lighting group to overcome the flipped emitter issue.

This was the only flipped room / light group and the only section of the model that caused the file from studio to not be rendered.

[JDHill]

Just don't forget that instances are not zero-weight things either. If the thing you're instancing is actually smaller (vertices, faces, etc.) data-wise than an instance (name, material, transformation, etc.), then you're going backwards. The general example would be grass: do not instance one blad a thousand times; rather, instance a hundred blades ten times. The balance depends on the actual situation.

As to the rest of what you wrote, implementation of interactive preview necessitates alot of rewriting in the export area, and I'll probably approach it quite differently, with the current issues regarding Studio in mind. Ironically, interactive preview will also further lessen the cases in which Studio might be used, but that's just how it goes.

[Richard]

Great point on the limiting of instance use JD - that is something I hadn't considered!

That does I guess bring up some questions, is there a way to avoid small objects as say a leaf on a tree created as a component to NOT instance other than making it a group? One may wish not to instance the leaf as suggested however not making it an instance would devoid it's global editability. Or does instancing only act on the upper level of component structure? Or could a proxy type tag indicate what should be instanced?

Re interactive render - mate I do understand that it will certainly reduce the reliance on Studio though we still have the import of high poly issue to overcome, that's the bugger! And now the fact one is forced into studio to generate a material ID map.

[Richard]

BTW mate must say it almost doesn't seem fair that with the interactive preview you may have to rewrite so much of the exporter! Aside from a few issues once we go to studio, this exporter is just a joy - I'm everyday impressed and that without the great plain english manual that accompanies it!.

[brodie_geers]

... And now the fact one is forced into studio to generate a material ID map.

eh? Why can't you generate a matID through the SU plugin?

-Brodie

[JDHill]

I think he means that the plugin's embedded material type doesn't currently support explicit mat ID color. Of course that's not the case when using a material's MXM mode.

[Richard]

Yeah the problem is in part as JD suggested using the plugin Mat ID colours can't be assigned, using MXM's they can however one still has to run a test to determine if the colour suite has clashes.

One feature I guess that would be cool to MR would be the creation of material masks (aka like the alpha map) for each material - maybe a big ask and MXI file size consumptive.

BTW I'm not saying the material ID issue is at all a big one! Sometimes I've just opened the file in studio set the material ID colours then saved back out the MXM's to replace the originals, hence my resent request to the MR wishlist for Material ID to be an option in the viewport.

[Richard]

Hey JD just a little bump on this question.

That does I guess bring up some questions, is there a way to avoid small objects as say a leaf on a tree created as a component to NOT instance other than making it a group? One may wish not to instance the leaf as suggested however not making it an instance would devoid it's global editability. Or does instancing only act on the upper level of component structure? Or could a proxy type tag indicate what should be instanced?

From the look of it, in Studio it may well be that a nested component are instanced as well. Would it at all be possible in any update of the plugin to elect not to instance nested components, for the exact reason you suggest? Losing global editability of nested components can be a significant loss on some objects.