MayatoIndigo Developement
MayatoIndigo Developement
SuperDupont?
I think it is safe to say that the development of MayaToIndigo is open, any
contributor is welcome. Hence a minimal structure is required, and that's
what this thread is supposed to be: a topic to discuss about orientations and
organizing development.
blank
I think it is safe to say that the development of MayaToIndigo is open, any
contributor is welcome. Hence a minimal structure is required, and that's
what this thread is supposed to be: a topic to discuss about orientations and
organizing development.
blank
Last edited by CTZn on Wed Nov 26, 2008 12:33 pm, edited 1 time in total.
I just don't know how that works but that'll come in time...
Few things we should discuss:
- The name: I like Mayingo, what do you think ?
- closed source code (like IME): I don't wan't to include anymore that kind of stuff into the project, now we're stuck with IME wich was a great addition in the past but now we can't make it evoluate; I suggest we left it appart (soon if not yet). Anyone can make a closed source exporter but it's likely he will work alone. I know yourdaftpunk made a v2 but he forget about us. Crap.
- well, what else ? Er... I'd like to have something like a "code tree", in order to expose and share the structure of the project. Would SVN allow this ?
Few things we should discuss:
- The name: I like Mayingo, what do you think ?
- closed source code (like IME): I don't wan't to include anymore that kind of stuff into the project, now we're stuck with IME wich was a great addition in the past but now we can't make it evoluate; I suggest we left it appart (soon if not yet). Anyone can make a closed source exporter but it's likely he will work alone. I know yourdaftpunk made a v2 but he forget about us. Crap.
- well, what else ? Er... I'd like to have something like a "code tree", in order to expose and share the structure of the project. Would SVN allow this ?
!
Concerning the name: I like Maya2Indigo or MayaToIndigo, or even mio...
Concerning closed-source exporters:
we could link the IME-Checkbox to a mti_UseExternalExporter script, call
whatever that script says and just get a string as a feedback, if somebody really feels the need to toy with something like that...
Concerning SVN: How complicated is it to use? And can we break the whole thing into small parts that interakt which each other, so when someone wants to improve a module, he just modifies that one.
I've made a small update to illustrate this principle (calling mti_MakeCameras.mel with some parameters to generate the camera data...)
(and integrated:
- a Locator-based approach to instancing, using a custom prefix attribute in the locators transform
- started with a simple script to sweep in predef shaders (custom attribute has to be assigned to a phong shader, feel extrrremely welcome to add your fav. shaders
- added an efficacy statement that interpretes the grey-value (color) of an emitter-shader as multiplicator (*100) to determine the wattage of the light.
)
regards !
[ Lets really prepare a simplified version of this script with a rudimentary tutorial explanation, and oui!, let's start recruiting once 0.7.6 of Indigo is released.]
Concerning the name: I like Maya2Indigo or MayaToIndigo, or even mio...
Concerning closed-source exporters:
we could link the IME-Checkbox to a mti_UseExternalExporter script, call
whatever that script says and just get a string as a feedback, if somebody really feels the need to toy with something like that...
Concerning SVN: How complicated is it to use? And can we break the whole thing into small parts that interakt which each other, so when someone wants to improve a module, he just modifies that one.
I've made a small update to illustrate this principle (calling mti_MakeCameras.mel with some parameters to generate the camera data...)
(and integrated:
- a Locator-based approach to instancing, using a custom prefix attribute in the locators transform
- started with a simple script to sweep in predef shaders (custom attribute has to be assigned to a phong shader, feel extrrremely welcome to add your fav. shaders
- added an efficacy statement that interpretes the grey-value (color) of an emitter-shader as multiplicator (*100) to determine the wattage of the light.
)
regards !
[ Lets really prepare a simplified version of this script with a rudimentary tutorial explanation, and oui!, let's start recruiting once 0.7.6 of Indigo is released.]
- Attachments
-
- Update.zip
- (22.55 KiB) Downloaded 399 times
Whatever you want my point was to avoid confusion with M2I (Max to Indigo). Like "blendigo", mayingo can not lead to confusion; but I don't care, it's just a nameConcerning the name: I like Maya2Indigo or MayaToIndigo, or even mio...
I know nothing about SVN, just that it is supposed to help with differents versions. As usual, Wikipedia can give an insight. Otherwise, a modular system is the best choice like you said.Concerning SVN:
If you mean commenting out the scripts and preparing them for modularity, let's rock it !Lets really prepare a simplified version of this script with a rudimentary tutorial explanation
May I watch you do ? you're so productive
Oh, I thought today that every developer could have it's own thread to post updates but SVN will save our mind I hope !
And for now I think that all that someone playing with the scripts has to do is to maintain a list of changes. Say the last version arneoog posted is the reference.
More Proposals:
IndigoOnMaya
MayaGo
MayaToIndigo
Besides, it would be great if arneoog could integrate one version
of MayaToIndigo once he's done with the materiallib, as the official starting-point. (Beginning next Weekend, isn't it?)
[ I'll post one update till then, fixing some bugs and clearing the interface somewhat...]
[And now to something completely different:]
Q 1: How do you get Indigo to start from the MayaUI?
Q 2: What is the rational behind the luminance/ gain settings for daylights?
I found the default settings not working.
IndigoOnMaya
MayaGo
MayaToIndigo
Besides, it would be great if arneoog could integrate one version
of MayaToIndigo once he's done with the materiallib, as the official starting-point. (Beginning next Weekend, isn't it?)
[ I'll post one update till then, fixing some bugs and clearing the interface somewhat...]
[And now to something completely different:]
Q 1: How do you get Indigo to start from the MayaUI?
Q 2: What is the rational behind the luminance/ gain settings for daylights?
I found the default settings not working.
Hehe
Maye I can do it next weekend
I'll then collect all MTI 0.7.xx updates into one, as the starting point
Q 1-A: This is something I've been trying to do for ages...
But I can't get it to understand that indigo.exe must be ran inside of it's directory...
Maybe find the mel script Maya uses to open FCheck...
Q 2-A: Ah, yes... That was a 0.7.3 indigo hack It should be removed..
PS: MayaToIndigo is still my favorite name
Maye I can do it next weekend
I'll then collect all MTI 0.7.xx updates into one, as the starting point
Q 1-A: This is something I've been trying to do for ages...
But I can't get it to understand that indigo.exe must be ran inside of it's directory...
Maybe find the mel script Maya uses to open FCheck...
Q 2-A: Ah, yes... That was a 0.7.3 indigo hack It should be removed..
PS: MayaToIndigo is still my favorite name
MayaToIndigo !
That could be the name we use for our project!
About Q1
Arne, I toyed with starting indigo from commandline, and it seems to kind of works:
try
$xmlFile = "1.xml"; // requires 1.xml in indigo-homedir
$threads = 1;
string $cmd_string = " cmd /k " + "cd \"d:\\program files\\indigo_07_test5\" && d: && dir && indigo.exe " + $xmlFile + " -t " + $threads + " && pause";
print ("CHECK\ncommand string: " +$cmd_string +"\n\n");
system ("start" + $cmd_string);
System is still complaining about inifile, but starts to render nonetheless.
(to read a nice piece of garbage, either check my addons to mtiGen or refer to cmd /?, I don't know what I like more. hehehehe.)
About Q2
There seems to be a power-drawn statement that is pretty cool and that has something like <overall luminous efficacy> that accompagnies it.
Anybody know what it does, and what should be our default for it?
I found out that with a gain of 1.0, you have to set <overall_luminous_efficacy> only to 1000000000000 to be well visible in sunlight. ???
</spectrum>
<efficacy_scale>
<power_drawn>50</power_drawn>
<overall_luminous_efficacy> 20 </overall_luminous_efficacy>
</efficacy_scale>
Q3:
If the <include> statement works as someone pointed kindly out,
we may have a problem hooking Alias-Shadernames up with static mti-Library-files. How do we cope with this?
One stomach turning method would be to rename all the shaders to correspond to the <material>statements of the lib on the fly while exporting, and changing them back later on.
I don't like that really much, what do you guys think (and gals out there, by the way, or do they know a better way to spend there time )
Q4:
Concerning F-Scale:
Is F-scale in any way influencing rendering speed (similar to a real camera)
I guess not, and then 50 is a pretty reasonable default, otherwise, let's check it...
That could be the name we use for our project!
About Q1
Arne, I toyed with starting indigo from commandline, and it seems to kind of works:
try
$xmlFile = "1.xml"; // requires 1.xml in indigo-homedir
$threads = 1;
string $cmd_string = " cmd /k " + "cd \"d:\\program files\\indigo_07_test5\" && d: && dir && indigo.exe " + $xmlFile + " -t " + $threads + " && pause";
print ("CHECK\ncommand string: " +$cmd_string +"\n\n");
system ("start" + $cmd_string);
System is still complaining about inifile, but starts to render nonetheless.
(to read a nice piece of garbage, either check my addons to mtiGen or refer to cmd /?, I don't know what I like more. hehehehe.)
About Q2
There seems to be a power-drawn statement that is pretty cool and that has something like <overall luminous efficacy> that accompagnies it.
Anybody know what it does, and what should be our default for it?
I found out that with a gain of 1.0, you have to set <overall_luminous_efficacy> only to 1000000000000 to be well visible in sunlight. ???
</spectrum>
<efficacy_scale>
<power_drawn>50</power_drawn>
<overall_luminous_efficacy> 20 </overall_luminous_efficacy>
</efficacy_scale>
Q3:
If the <include> statement works as someone pointed kindly out,
we may have a problem hooking Alias-Shadernames up with static mti-Library-files. How do we cope with this?
One stomach turning method would be to rename all the shaders to correspond to the <material>statements of the lib on the fly while exporting, and changing them back later on.
I don't like that really much, what do you guys think (and gals out there, by the way, or do they know a better way to spend there time )
Q4:
Concerning F-Scale:
Is F-scale in any way influencing rendering speed (similar to a real camera)
I guess not, and then 50 is a pretty reasonable default, otherwise, let's check it...
Who is online
Users browsing this forum: No registered users and 28 guests