Indigo Renderer Forum

REV 173
added deg_to_rad convertion in mti_ExportModuleCamera.mel - apertureshape::generated::start_angle
fixed nk_data XML formatting
added switch..case in mti_Gen.mel for detecting windows/linux so that we can write the correct commands.

I think we should give a copy of this revision to phr0stbyte to test.

edit: If there's anyone here on linux or mac, can you test the attached version and report back with what happens when you try to use renderDirect. We need your input to get this right (as I for one only have Maya on windows).

REV 174
fixed export visible. also implemented use of display layers.
Object only exported if it's on a visible display layer, and it's not itself hidden.

That's some dramatically handy stuff Doug ! And nice that it works both ways.

Actually, I've found that the new Export Visible code doesn't work correctly... parented objects don't work.

What we actually need is a full scene-traversal proc that starts with displayLayers (also had some problems where defaultLayer wasn't being recognised), and starts to pick off visible children and store meshes, transforms, and shaders into different arrays that we then use in other Export modules.
I also notice that some parts of mti_Gen are using their own `ls ...` commands, where really we should traverse the scene just once at the start of the script, picking off the nodes that we are interested in and then make the rest of the exporter refer back to these master lists.

One big problem with doing all this is.... it's hideously complicated (i mean, from a coding point of view - it'll be wonderful to actually use when it works )

[side note, actually the beauty of using `ls -s` is that all nodes are returned, regardless of parenting. In fact if we can find out what displayLayer an object is on from it's name, rather than the other way around, this might be a better way of doing it]

REV 176
Fixed saveVisibleOnly with display Layer and parented object support

It actually wasn't that complicated when starting from `ls -s`.

I think we should now look at other parts of the script, and make sure they are all using the proper $shapes, $meshes and $transform lists, rather than regenerating them all the time.
Then, tests like in modules (eg, ExportModuleObjects) should be redundant and can be removed.

I hope you have commented your script

When I think about where we want MtI to go, I'm telling myself that there would have to be a structural change, maybe it started now...

See, now only am I getting right what is happening on your avatar

haha, my avatar is one of the very first things I rendered with indigo - my first fibre optic experiment. It was modelled in blender though.

as for the script, it's fairly easy to follow..
we start with a few variations of `ls -s` and then if savVisible is true, that selection is filtered according to a couple of helper functions' outputs. (ie, if the object itself is visible, and if it's display layer is visible).

Pretty straight forward !

So far, I could export an heavy scene (2171 simple true objs, no instances) with all the objects grouped and such, really that's mind-blowing how versatile turned MtI these last times ! That said it took 10mn to export, writing all these objects to disk took 7mn+ ...

bkircher was the little brise reviving the Maya forum and MtI, then Doug, you've been a meccano storm upon it.

Thanks all !

Me doing some modest corners rounding, at the periphery Seems that <aperture_diffraction> should not be set in <render_settings>, added date stamp at the end of export, commented feedback line for skipped objs (2000+ then) etc but not submitted yet. In fact I'm not fancy submitting, I feel I don't have enough control/understanding on the scripts suite for that. That may take some time.

Cheers !

CTZn:
you should commit the datestamp and removed feedback line, I've no problem with that.

As for <aperture_diffraction> in <render_settings>, well it's the only way we can reliably control it. I for one don't ever edit my inifile, but others might and leaving the setting out might have unpredictable results for some people.
I think it should stay in render_settings.

I've been a bit absent the last couple of days, and will likely remain so - there's a few important web projects happening at work which is taking all my time. I will probably head back this way towards the end of next week.

okay, I may commit within 48h then, I will see what addition could be worse it meanwhile.

Okay as well for aperture diffraction, specifically if that works that way. My point was that I had issues yesterday (Indigo 1.0.4 running in 1.0.2 folder, throwing an error because "'aperture_diffraction' isn't in the map" ie not in 1.0.2 inifile), and while helping me to debug psor insited on that I had to remove that line from render_settings, that was not it's place to be. But if that works it will stay here

Good luck for your job !

OK... I have encountered a little strangeness here..... (got UV-Mapping figured out, by the way. Thanx, guys).

Check out the iPod screenshot from within Maya and then look what Indigo produced. I am refering to the iPod screen here - in the Indigo render, it is way off center. Whats up with that?

Using the latest MtI 0.9 with the SVN update. I can provide the Maya scene and/or Indigo XML if needed.

ok.. finally a bug report !!

I have a few questions, if I may.
1. Which exact revision of MtI were you using?

2. Was the export process aborted at any time?
- The newest code uses a new method for exporting objects whereby they each get temporarily moved to the origin (and then back to their original locations). If the process is interrupted, objects can be left there.
[As an aside, I would like to hear suggestions as to how we might be able to avoid this problem - this occurs particularly if you choose "cancel" to the "File exists, Overwrite?" prompt.]

3. Are any of the ojbects parented/grouped/constrained to any other?

4. Are any of the translate attributes locked on any object?
(the code mentioned in Q#2 above won't be able to move the objects about if translate is locked, the exported object will then render with an offset in the opposite direction to it's translation)

As I really have no idea what you are saying (too technical - I just like to model stuff and make pretty pictures...), I am including the maya scene and xml output.

Using Maya 8.5 (linux x64)
Indigo 1.0.4 (via wine 0.9.47)
MayaToIndigo09_20071129
MtI-svn-rev173

As a side note, I seem to have heard issues with other Indigo scripts exporting scenes with no mats - maybe this is why? I will add mats later to check it out. I dont think the script was interupted, as I got a finish status in the status area at the bottom of Maya. Also no objects are tied or grouped together.

ok, the scene file is useful. having a look now.

edit: yeah it renders the same here. very strange. i can't explain it yet.

edit edit:
Freezing xforms has no effect (they are frozen already)
Deleting all history has no effect (there is no history)
There's nothing wrong with the exported .obj files either - if you re-import them 1 by 1, they come back in exactly the right place.

Also, grabbing the parts from the scene you provided, and translating and rotating them has no effect.

I think we could file a bug report against this one