MtI rev 32 29 oct 2007

Announcements, requests and support regarding the MAYA exporter
User avatar
dougal2
Developer
Posts: 2532
Joined: Wed Nov 15, 2006 8:17 am
Location: South London

Post by dougal2 » Mon Nov 05, 2007 9:15 am

well, my reasoning with point #2 is:
2.0 as a post scale is too high. details get bleached out and lots of information lost.
2/1/6 gives a nice preview, and I think that if you were doing any serious work you'd save the IGI and tonemap as a post process.

User avatar
CTZn
Posts: 7240
Joined: Thu Nov 16, 2006 4:34 pm
Location: Paris, France

Post by CTZn » Mon Nov 05, 2007 9:30 am

Well for some reason I don't trust much Violet. You settings are indeed better than the previous, specially post-scale.
obsolete asset

bkircher
Posts: 115
Joined: Thu Nov 23, 2006 6:24 am

Post by bkircher » Tue Nov 06, 2007 4:41 am

Concerning the camera: I used what was available in mti 0.7x,
and never understood it. I made two changes: One was empirically changing a factor for the lense, but later I thought that was not that bright an idea.
Recently, i added a 35mm camera assumption, which is close enough,
though still misfitting (see your image, cool that you have a look into the presets)

btw., presets ignore all values not set, I think (have to check, though!), so we could make "HowToUsePhong",... settings and also presets like "ScenesWithSunLightingOnly"; "SSS_HighAccuracy"; "FireFlyReductionAtSSSAcc".

We need cm-scaling. The wavelength of light stays fixed in a scene with absurd dimension, so chromatic aberration and other effects should look weird.
Our film is still a 35mm film in a giants world, to my understanding, DoF can't work properly. How do you make DoF instead of using absurdly low F-Stop values? (I don't use DoF, but for the risk of f*cking up otherwise perfectly neat renderings).

Finally, once we get IES-Profiles, they will use real-world units for light intensities.

User avatar
dougal2
Developer
Posts: 2532
Joined: Wed Nov 15, 2006 8:17 am
Location: South London

Post by dougal2 » Tue Nov 06, 2007 5:03 am

Have you read Ono's guide for export writers?
He updated it recently with equations on how to translate camera settings.
I might have a look this evening at our code and see how it compares.
There's no reason we shouldn't be able to get a correct setup with the information given.

User avatar
dougal2
Developer
Posts: 2532
Joined: Wed Nov 15, 2006 8:17 am
Location: South London

Post by dougal2 » Tue Nov 06, 2007 10:23 am

I've looked at the camera code:
I went ahead and renamed some of the variables in the process, to make it easier to understand.
I think aperture_radius was being incorrectly calculated.
I've done a few tests and the scene framing seems to be much better now.

REV 56
- corrected camera
- removed OBACHT/shader debug print() output

User avatar
CTZn
Posts: 7240
Joined: Thu Nov 16, 2006 4:34 pm
Location: Paris, France

Post by CTZn » Tue Nov 06, 2007 12:28 pm

Sounds interesting Dougal ! I will test last rev for my dumb scene I've been working on lately.

If I remember correctly I reported once that scale issue in Maya, I was requesting a switch in Indigo to allow centimeters as input instead of meter. IIRC then, I've been told that the settings for DoF (don't remember the name oops) could be scaled x100 straight away. Then maybe scaling won't be an issue anymore. The thing to keep in mind then is to use 1 Maya cm as 1 Indigo meter. Yes I'm repeating myself ;)
obsolete asset

bkircher
Posts: 115
Joined: Thu Nov 23, 2006 6:24 am

Post by bkircher » Tue Nov 06, 2007 7:03 pm

Cool, let's keep on repeating ourselfes :wink: (good thing though, if we can scale F-Stop manually).

Apart from that, Indigo is based on some physical properties of light: As Ono is getting more realistic, a *100 Scene-Scale factor will be questionable.

Moreover, we have to put this way of thinking into every detail we create.
(the bump depth has to be very small, light-intensities have to be raised by huge amounts).

Anyway, I'll grab the mti_Gen.mel and mti_ExportModuleCamera.mel and add a global scale factor to them (default will be 1), so that we all can have a look into this :wink:

As a goody, I'll try to throw in a sketch for randomizing the upRotation, though that would need more custom attributes in the Locators (mtiRotationRandomRange).

Just commited global scaling, try with values of 0.5 (mti_Gen), see that up is still weird.

User avatar
CTZn
Posts: 7240
Joined: Thu Nov 16, 2006 4:34 pm
Location: Paris, France

Post by CTZn » Wed Nov 07, 2007 11:18 am

As a goody, I'll try to throw in a sketch for randomizing the upRotation, though that would need more custom attributes in the Locators (mtiRotationRandomRange).
Hello bkircher,

Have you considered adding those attributes to a new node, that would hold the informations for all instances in the scene ? I would like to see the objectEditor revived, your thoughts on that point please ! Through that editor we could have access to the list of instancing operations in the scene, and set their attributes at will there.

Example:

- say you want an object aA to be instanced in the scene; some of its instances must have the original orientation while others will have, say, random rotations around up axis.
- user will then call twice an instancing action. Upon first instancing operation, a node will be created that will store references to aA and locators involved in instancing operation. Next operation will be stored by the same mean, in the very same node (let's call it mti_Instanciator for demonstration purposes). By the way everay operation would have it's own name (suggesting "mti_INST_" + $nameOfObject + "_" + $numOfLocators + "_";, ie mti_INST_sphere1_6_) making it accessible through the previously named editor.
- in that editor the user will set attributes for every single instancing operation.

That would provide more flexibility at a later time, I believe. Thoughts again, see any issue coming out that plan ?
Last edited by CTZn on Wed Nov 07, 2007 11:27 am, edited 1 time in total.
obsolete asset

User avatar
dougal2
Developer
Posts: 2532
Joined: Wed Nov 15, 2006 8:17 am
Location: South London

Post by dougal2 » Wed Nov 07, 2007 11:24 am

btw, i've been looking at materials and textures and things.
I imported one of the material preview scenes from blender, and converted it to a maya scene. I've committed it to the SVN, although I forgot the jpg textures :oops: i'll add them next time.

I'm now re-rendering our existing materials using this scene.

User avatar
CTZn
Posts: 7240
Joined: Thu Nov 16, 2006 4:34 pm
Location: Paris, France

Post by CTZn » Thu Nov 08, 2007 8:35 am

I had new directives incoming from my friend for rotMats. I just implemented the new model but I don't have the time right now to test it, will do later in the night. I think I noticed some disfunctions in r58, I will report or correct them if that is confirmed.
obsolete asset

bkircher
Posts: 115
Joined: Thu Nov 23, 2006 6:24 am

Post by bkircher » Thu Nov 08, 2007 12:40 pm

Rev 60:

- Many mti-settings are now keyable and can be modified in the channel box
- added a Global Factor Setting, default 1, not working properly with camera yet
- added an UpRandomRotation element to locators. Works in principle but has to be checked.
- added a sketch of the camera settings, but got stuck, so they are just a heap of comments.
- added sample presets of the mti-settings element.

I'll take a vacation from mti for a week:
The camera export is not making progress,
or it is, but it's still looking all wrong. I've appended my sketch and what I found in an AE-Template in the mti_ExportModuleCamera.
(And I'm pissed because Maya won't give the FoV straight away, and mixing Inches, millimeters and centimeters and trying to get that to work with a program based on milimeters, not to forget the deg_to_rad conversion...)

so long...

User avatar
CTZn
Posts: 7240
Joined: Thu Nov 16, 2006 4:34 pm
Location: Paris, France

Post by CTZn » Thu Nov 08, 2007 3:24 pm

Good work so far bkircher ! You did a lot (special thanks for obj exporter and initial instancing system), have a rest ;)

- - - - -

*EDIT* FIXED: ROTATION MATRICES WOOHOO

Thanks to GuiGui for the invaluable help :D He did solve the problem into a simple and robust setup. For some reason I had to invert all input angles, plus swap Y/-Z, but he did the rest.

Cheers !
Attachments
RMZUP_falseColors.png
bottom left is original and top right is facing him, involving rotations with all angles. Colors are post, representing the axe on wich a single rotation is applied. Final result is 100% satisfactory.
RMZUP_falseColors.png (114.85 KiB) Viewed 4029 times
Last edited by CTZn on Thu Nov 08, 2007 7:09 pm, edited 1 time in total.
obsolete asset

User avatar
CTZn
Posts: 7240
Joined: Thu Nov 16, 2006 4:34 pm
Location: Paris, France

Post by CTZn » Thu Nov 08, 2007 7:08 pm

Rev: 61
obsolete asset

User avatar
dougal2
Developer
Posts: 2532
Joined: Wed Nov 15, 2006 8:17 am
Location: South London

Post by dougal2 » Thu Nov 08, 2007 10:13 pm

cool! i knew you'd crack it.

shall we release this revision?

User avatar
CTZn
Posts: 7240
Joined: Thu Nov 16, 2006 4:34 pm
Location: Paris, France

Post by CTZn » Fri Nov 09, 2007 5:46 am

Well again if there wasn't my friend to provide the necessary help I would have just been cracked by these strange mathematical entities; thus the line he deserves on top of mtiGen script. Anyhow please test the feature yourselves, as usual.

As for a release: indeed I think we are close(r) to a release state, but is MtI yet objectively easy to use ? The three of us know the features and caveheats quite well, but:
  • - the documentation is non exhaustive yet, very frustrating for new users.
    - menus are a mess, and features are missing (Load Settings from File, mti_makeInstances, ...). Every command working with icons should be present in the menus.
    - certainly are there more reasons not to release MtI yet.
we should try to complete that list and fix it before thinking about a public release, IMHO.

Thoughts ?
obsolete asset

Post Reply
105 posts

Who is online

Users browsing this forum: No registered users and 1 guest