MtI 0.9 (19 nov 2007 release)

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 » Thu Nov 22, 2007 12:28 pm

note to self, mostly:

indigo supports it's own embedded meshes.

Code: Select all

<mesh>
	<name>mesh1</name>
	<normal_smoothing>false</normal_smoothing>
	<embedded>
		<expose_uv_set>
			<index>0</index>
			<name>albedo</name>
		</expose_uv_set>
		<expose_uv_set>
			<index>0</index>
			<name>bump</name>
		</expose_uv_set>
		<vertex pos="-10 -10 0" normal="0 0 1" uv0="0 0" />
		<vertex pos="-10 10 0" normal="0 0 1" uv0="0 10" />
		<vertex pos="10 10 0" normal="0 0 1" uv0="10 10" />
		<vertex pos="10 -10 0" normal="0 0 1" uv0="10 0" />
		<triangle_set>
			<material_name>white</material_name>
			<tri>0 1 2</tri>
			<tri>0 2 3</tri>
		</triangle_set>
		<vertex pos="-10 3 0" normal="0 -1 1" uv0="0 0" />
		<vertex pos="-10 3 20" normal="0 -1 1" uv0="0 10" />
		<vertex pos="10 3 20" normal="0 -1 1" uv0="10 10" />
		<vertex pos="10 3 0" normal="0 -1 1" uv0="10 0" />
		<triangle_set>
			<material_name>checker</material_name>
			<tri>4 5 6</tri>
			<tri>4 6 7</tri>
		</triangle_set>
	</embedded>
</mesh>
perhaps i'll have a go at writing an export module for this object format at the weekend... it might get around the limitation of using objs.

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

Post by bkircher » Thu Nov 22, 2007 7:32 pm

1. sorry for not incl. GUITools, maybe some error while commiting...
2. We could translate the <mesh> (.obj) inversely and do translate + scale + rotate with the <model> element
3. The option to write meshes directly would be very nice sometimes, but I have the feeling that invites trouble:
I like the .obj way since special plugins tend to get outdated,
and mel-scripts for large meshes might prove slow. (Nice for multi-UV).

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

Post by dougal2 » Fri Nov 23, 2007 7:42 am

any chance of comitting those missing files this evening?

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

Post by bkircher » Fri Nov 23, 2007 8:43 am

upped missing files...

If you check the very first indigo-exporter´s, they had a built in mesh-export funvtionality. Often created messy files with many objects, imho.
Last edited by bkircher on Fri Nov 23, 2007 8:45 am, edited 1 time in total.

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

Post by dougal2 » Fri Nov 23, 2007 8:44 am

cheers :)

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

Post by bkircher » Fri Nov 23, 2007 8:48 am

:)

not the right forum, but as you've worked on violet: do you know if the code is available? may pm you on this, as I think that may be a very promising field of work...

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

Post by dougal2 » Fri Nov 23, 2007 8:53 am

actually, it's still not working.

Code: Select all

// Error: Object not found: mtiIndigoCameraButton // 
I even added a call to mti_ModuleGUITools; in mti_Main but it's still not working.



As for as Violet goes, iirc the latest developments were done by rerdavis and the change that I made prior to that were merged into his source.
His latest source is available here:
http://www.indigorenderer.com/joomla/fo ... php?t=1973

I also found that the binaries I made were not as stable as those produced by Ono and rerdavis. I'm not so sure what's so special about their compilers :?

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

Post by dougal2 » Fri Nov 23, 2007 12:20 pm

REV 138

ANIMATION! :D

mti_ExportModuleShaders.mel:
corrected a couple of CRLF errors

Other updates are to do with Animation implementation:
mti_Gen.mel:
Split out Render launcher into a separate proc, added functionality to render a batch in one go.
the old mti_Gen() proc has been renamed and now takes arguments, and returns the path+name of the generated XML file.
the new mti_Gen() proc detects animation settings, and exports the frame range. RenderProc() is called from here once export is complete.
NOTE: objs are now saved to <scene dir>/objs/<frame number>/ regardless of whether animation is enabled or not.
mti_RenderProc() takes a stringArray of xmlFiles to render, creates a batch file and executes it.

mti_Main:
added animation checkbox
(also attempt to fix bkircher's broken code; didn't work)

mti_ScriptNode.mel:
added animation option.


WARNING:
the animation export works, but I still need to add a few sanity checks into the animation launch proc, so that your system doesn't get killed by trying to render all frames at once.
By all means try it with a few frames at a time (erm, < 5? ) for now.

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

Post by bkircher » Fri Nov 23, 2007 8:02 pm

Has to be checked with mti_Main (will do this evening except if someone else fixes first):

mtiIndigoCameraButton
mtiIndigoSunButton

are the names of the UI elements, same as they are referenced with in mti_ModuleGUITools...

Animation: Cool!

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

Post by bkircher » Sat Nov 24, 2007 8:17 am

I propose a halt to new features and a thorough cleaning of mti.

Lets split all complicated Elements into components,
and let's build mti_Main so that it collects all user-settings at the beginning,
passing them to all modules as fitting.

I've split out the Model-Generating part, but frankly, I don't grasp the connection between mti_Gen and the other modules, so I'm not going to commit but rather, post it as a file.

Besides, do we have a problem with the memory footprint?
I do agree that that makes sense with instances, but maybe it's not necessary with models et al.

(Don't get me wrong, the changes are really cool, but I don't have the necessary time and concentration for this complex building mti is becoming.)
Attachments
mti_ExportModuleModels.zip
(6.44 KiB) Downloaded 108 times

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

Post by dougal2 » Sat Nov 24, 2007 8:30 am

bkircher wrote:I'm not going to commit but rather, post it as a file.
thanks for that... there's some strange changes in there IMO.

My PC is busy with these Camera Tonemapping renders at the minute, but when they're done, I'll split the Model Export out into a file as you did - that makes sense to do. Perhaps meshlights can be a module too.

I will then finish off the animation code, and write the documentation for the bits I've added in the last couple of days.

Also, perhaps we need some developer documentation to explain each file and what each function is for? That might save some confusion and each of us having to work out every new piece of logic individually.
It might also help us to spot any bugs in case what we scripted wasn't what we intended.

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

Post by bkircher » Sat Nov 24, 2007 8:59 am

cool.

really, let's unify how we treat modules, so that most paramters are collected globally and passed to the tool-modules in a common fashion, and only module specific items are collected there.

Thus, Ideally, mti_Gen would read:

Code: Select all

global proc mti_Gen ()
{
         /*
         mti_Gen collects all global attributes, calls all mti_Export Modules   
         that write the geometries, define the <meshes>, define the 
         <models>, and generate additional <models> from instances.
         */

         string $saveFile = `getAttr ...`;
         string etc.

         for (all frames to be rendered)
         {

                  // Generate Basic Settings        
                  $mtiWrite = `mti_ExportModuleXY $bla $bla $blubb`;
         
                  // Generate Camera
                  $mtiWrite = `mti_ExportModuleCamera` $bla $bla $bluxx`;

                  [...]

                  // Generate Models from Instance Locators
                  // Note that here, Models definitions are directly written to the 
                  // xml file to better export huge numbers of objects
 


         }

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

Post by dougal2 » Sat Nov 24, 2007 9:05 am

yeah, I agree. I'll go through and add more comments as well.

I think each file should have a header with a summary of what it does, and then each proc should have a header explaining it's precise function and it's input(s)/output(s).

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

Post by CTZn » Sat Nov 24, 2007 10:00 am

Still observing, you are doing well both. Cleaning is a good idea. I wished that was done before. Dougal, I'm amazed on how fast you adapted your skills to mel !
obsolete asset

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

Post by dougal2 » Sat Nov 24, 2007 11:38 am

REV 141

- Created file headers
- Added proc descriptions
[CTZn/bkircher: please add description of makeInstances proc]
- tidied a couple of GUI functions into ModuleGUITools

Post Reply
88 posts

Who is online

Users browsing this forum: No registered users and 1 guest