Indigo Renderer Forum

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.

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

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.

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.

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

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

Cool, let's keep on repeating ourselfes (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

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.

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 ?

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 i'll add them next time.

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

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.

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...

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 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 !

cool! i knew you'd crack it.

shall we release this revision?

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 ?