MtI rev 63 08 nov 2007

bkircher · Post by **bkircher** » Mon Nov 12, 2007 6:24 am

Maybe we place them into a collapsible row so everybody not comfortable with them can toggle them off.

I found them very helpful to have at hand: I come from NURBS modeling,
and changing the face-normals frequently is for me a indigo specific thing,
related to lights, transparent sss-surfaces and exit portals.

Concerning the cam-scale: the geometry is scaled by the same factor as the camera.

... to be continued...

CTZn · Post by **CTZn** » Mon Nov 12, 2007 6:36 am

I found them very helpful to have at hand: I come from NURBS modeling, and changing the face-normals frequently is for me a indigo specific thing

That was my point, IMHO that is not specific to Indigo, but to your workflow

That's a perceptible detail, tends to make it more an "all-joy-toolbox" than a profesional and focused tool. For me using Hotbox it's still a click away... but I can't refuse that if you want, I'm just arguing

bkircher · Post by **bkircher** » Mon Nov 12, 2007 7:19 am

Your right, and we can have a look how to weed that box out somewhat.
On the other hand, giving new users access to these tools shows that they are related to Indigo: It's not a perception thing, Indigo needs normals, smooth shading instructions: It's the way we implemented it, among other things.

dougal2 · Post by **dougal2** » Mon Nov 12, 2007 9:18 am

bkircher --- I've fixed global scaling. If you release your file locks and let me commit, I'll show you why

edit: ok, being a bit more cooperative...
in the camera module, you need to be scaling mFocusDistance, not mFocalLength.

in mti_Gen we were scaling all meshes AND models. only scaling the meshes is necessary.
line 221, scale = mtiGSF
line 250 + 283 + 292, scale = 1

left to right: 10.0 1.0 0.1

dougal2 · Post by **dougal2** » Mon Nov 12, 2007 11:12 am

just did a couple more tests to see if I was right... by looking at the autofocus distance.

Maya scene is camera 3 units back from a plane (3cm) pointing straight at it. plane + camera aim is at the origin.

Code: Select all

GSF		autofocus distance
10.000		30.000m
1.000		3.000m
0.100		0.300m
0.010		0.050m
0.001		0.050m

seems like indigo has a mininum autofocus distance...

Otherwise it seems correct.

also, just found a bug in what I said earier.. mFocusDistance shouldn't be scaled either. ie. no occurrences of mtiGSF_Cam after my comment

Code: Select all

//	DH resetting camera according to exporter guide.

dougal2 · Post by **dougal2** » Mon Nov 12, 2007 11:37 am

i've also realised that diffuse_transmitter ought to be used if a standard lambert has transparency != black, and standard diffuse otherwise. no point in using anisotropic shader for this purpose.

i think a similar approach should be used for switching between specular and glossy_transparent (although not with the transparency attr, something else), as they are very similar materials (in my experience anyway).

dougal2 · Post by **dougal2** » Mon Nov 12, 2007 12:09 pm

bkircher, I looked at the details of your SVN lock and it was from yesterday... I assume you forgot about it?

I removed the lock and comitted the working GSF code.

I know I said to use locks to start with, but I didn't really understand SVN that well when I wrote that. There shouldn't actually be any need to locks files while you work. Your SVN client will alert you to any changes/conflicts when you commit... and when you update, local changes are kept/merged with the downloaded version. No code ever gets lost

REV 92
- fixed global scaling

CTZn · Post by **CTZn** » Mon Nov 12, 2007 12:33 pm

I've also realised that diffuse_transmitter ought to be used if a standard lambert has transparency != black, and standard diffuse otherwise. no point in using anisotropic shader for this purpose.

i think a similar approach should be used for switching between specular and glossy_transparent (although not with the transparency attr, something else), as they are very similar materials (in my experience anyway).

I do agree with you at 100%, and nice one Doug !

bkircher, the simple fact that you get my point is plently satisfactory for me, really I wanted to sensibilize you on that topic. Being objective is not always the easiest part of coding

Yep I always update/check again before commiting, precisely because I'm not at ease with locks. If there has been an update in the hour I use the comparing feature to manually merge code, if necessary.

bkircher · Post by **bkircher** » Mon Nov 12, 2007 8:59 pm

Great, and thanks a lot !

(sorry for the lock (which normally I don't use)).

What's up next ?

CTZn · Post by **CTZn** » Mon Nov 12, 2007 9:43 pm

I'm following alone my quest against toolboxes by upgrading mti_makeInstances further. That single button will have more uses: a call to mti_MakeLocator_Proc if you don't mind, and 1:1 instancing of any number of selected meshes (eg 1 assigned locator per selected mesh. The locators can then be duplicated at will).

You tell me what's next, I've followed from a distance all the recent changes and there were a lot, and have focused dev on "my baby" only. Now I want to do more !

Btw congrats, it's exporting nicely. Only doubt concerns cameras but the test scene was huge and I could not render it before, anyway... Cameras ? Scaling ? Shall we not revert that all to previous (aka "classic") mode, or is that fixed ? Mmh r92 says yes, going to make sure soon

Good day !

dougal2 · Post by **dougal2** » Mon Nov 12, 2007 11:30 pm

i'm far too busy for the next couple of days to make any changes.

I think scaling is fixed. I think the camera is stable and useable.

I think we could release a "stable" tomorrow if you guys can just check the bugs&notes that I've posted in this thread, check the TODO.txt and do some testing.

but then again, i don't see that many other users in this forum... who exactly are we releasing to?

Is there anyone else here (ie, not myself, CTZn or bkircher) who wants to suggest anything, or wants to test the exporter before it's called stable?

CTZn · Post by **CTZn** » Tue Nov 13, 2007 12:03 am

Sorry Doug that's me again :/

If we stop developing then we need to test extensively before releasing, give us 48h ok ? You'll be set then

Updating doc, about to commit.

dougal2 · Post by **dougal2** » Tue Nov 13, 2007 12:33 am

RenderDirect isn't working here at work.

need to make the system() command

shell cmd /c start ......

CTZn · Post by **CTZn** » Tue Nov 13, 2007 1:00 am

Yeah, forget about that until Ono removes the inifile dependancy. That's why I don't see the point on copying folders in Indigo App Dir, that doesn't even work. Everyone chocked his head against that one. The SendTo technique can not be passed as a system command ?

r93, improved mti_makeInstances, see documentation.

bkircher, mti_MakeLocator_Proc can now be called from mti_makeInstances, we don't need two icons anymore, choose the one ! And also in doc please explain better other instancing methods when you have time. Discard the new text formating if that's bugging you. Please test new instancing functionalities.

dougal2 · Post by **dougal2** » Tue Nov 13, 2007 1:41 am

CTZn, are you using LocalSaveDir?

perhaps this should be renamed SceneSavDir, as that is what it really is and it would help the user understand what it's for.

ie. I have:

IndigoDir = r:\indigo\indigo_v1.0.3\
LocalDir = r:\indigo\scenes\

and

r:\indigo\scenes\objs\
r:\indigo\scenes\environements\
r:\indigo\scenes\textures\
r:\indigo\ies\

and I set

ObjDir = objs/
TextureDir = textures/
environDir = environements/
iesDir = ../ies/

using localSavDir, the XML file ends up in r:\indigo\scenes\ and objs in r:\indigo\scenes\objs\ and ies files are referenced to r:\indigo\ies\

MtI rev 63 08 nov 2007

Who is online