The LFA Scene Manager for MAYA

The place for artists, modellers, level designers et al to discuss their approaches for creating content for OGRE.
Post Reply
Vectrex
Ogre Magi
Posts: 1266
Joined: Tue Aug 12, 2003 1:53 am
Location: Melbourne, Australia
x 1
Contact:

Post by Vectrex »

no don't worry, it's a simple high level scene xml format, no verticies to worry about. It uses .mesh references

User avatar
psyclonist
OGRE Expert User
OGRE Expert User
Posts: 286
Joined: Fri Nov 01, 2002 3:54 pm
Location: Berlin & Nuremberg, Germany
x 1
Contact:

Post by psyclonist »

metaldev wrote:well i believe that you did answer my question -which more clearly stated is: if the actual vertex data for entities is contained inside the .scene format... which from your response i take to be yes.
No! .scene only references .mesh files.

-psy

User avatar
metaldev
Orc Shaman
Posts: 761
Joined: Thu Mar 17, 2005 11:56 pm
Location: Boston
x 12
Contact:

Post by metaldev »

lol, sounds good then! ill see if i can adapt my mel :D

Bringer of Darkness
Halfling
Posts: 98
Joined: Thu May 05, 2005 3:57 pm

Post by Bringer of Darkness »

Well, it sounds to me like .scene format weill be quite similar to your format you have created::-)
Anyway, for the .mesh ocnversion problem - yes, the .xml files are all exported correctly. But the conversion to .mesh files is not always being realized:-)
I am running at 2.5GHz...

Bringer of Darkness
Halfling
Posts: 98
Joined: Thu May 05, 2005 3:57 pm

Post by Bringer of Darkness »

Mhm, I found an other problem I am encountering sometimes from time to time:
The transformations as it shows up in Maya aren't exactly the transformations that appears in Ogre. For example, let me say I rotate bunch of grass, in Maya it appears fine on place, but once it is exported to Ogre, it is rotated according to incorrect axes, so it is turned upside down...

Also sometimes the translate coordinates are weird. Any ideas?

>>Ok, have spent a few hours playing around and searching for problem solutions.
We have realized, that switching rotation in our engine to world space has the desired effect and the objects are rotated correctly. Not sure how other effects this may have though, if not some unwanted.
As for translations - we have had similar problem - some objects were simply misplaced. Using xform for getting pivot placement when exporting translations helps to fix this.
It is only needed to use the command when writing down to the file - somehow in the folowing manner, I hope it will help someone who has the same.similar problems;-))):

float $transformacie[];
$transformacie = `xform -q -rp -ws $currentObject`;
fprint $fileID ("tx "+`getNiceValue ($transformacie[0])`+"\n");
fprint $fileID ("ty "+`getNiceValue ($transformacie[1])`+"\n");
fprint $fileID ("tz "+`getNiceValue ($transformacie[2])`+"\n");

User avatar
metaldev
Orc Shaman
Posts: 761
Joined: Thu Mar 17, 2005 11:56 pm
Location: Boston
x 12
Contact:

Post by metaldev »

Those orientations are actually correct...( if you used the reset tranformations tool i provided before exporting). It looks like my reset transform might have a similar effect than the script you posted. The exporter makes it so all objects are exported as if oriented to world so that the data file can place them correctly relative to each other... when i port the whole thing to use .scene it should work out... just give me a couple weeks i got a lot on my plate at the moment.. but it will come :) (if you are in a big hurry you can use the data provided in the .lfa, the correct orientations for your objects will be held in there)

Bringer of Darkness
Halfling
Posts: 98
Joined: Thu May 05, 2005 3:57 pm

Post by Bringer of Darkness »

Truth, it seems it does the same or more or less the same;-)

But anyway, I find that there is still some problem remaining even with this "reset transformations"we do use.
The problem appears when realizing the steps as follows (I think):-)):
1. Create a new object somewhere away from 0,0,0
2. This means it will have its transformation pivot (world scale/rotate pivot) not at 0,0,0, while having the transformation at 0,0,0
3. This can be realized in the way that for example create cube, move it away from origin, separate a part of the cube and delete its history, you will have a new object that meets the requirements;-)))
4. Now copy and move several copies/instances over the scene.
5. If you will export .lfa file and check it in the engine now, the positions of the objects sucks completely...
I guess this should work for you as well. Any ideas how this can be fixed?

User avatar
metaldev
Orc Shaman
Posts: 761
Joined: Thu Mar 17, 2005 11:56 pm
Location: Boston
x 12
Contact:

Post by metaldev »

i dont have a method to see whats wrong at the moment :? ( i don't have a way to read the lfa yet.) How are you testing this btw?

Bringer of Darkness
Halfling
Posts: 98
Joined: Thu May 05, 2005 3:57 pm

Post by Bringer of Darkness »

Hmm, I import it into our engine;-))
The coordinates are orrectly taken from Maya channel box, but these are somehow relative to pivot/origin.
In case you have pivot/origin in the object (and this is out of center of coord system), you will receive position 0,0,0 even if the real position is different... And possibly once you copy this objet, the coordinates of new duplicate is relative to the original object - this means again incorrect;-)

Bringer of Darkness
Halfling
Posts: 98
Joined: Thu May 05, 2005 3:57 pm

Post by Bringer of Darkness »

Mhm, I just realized that there is another point worth fixing:-) - the procedure getNiceValue... :lol:

The problem comes in case the value is too small - otherwise said for example in my case:
7.019583574e-015
The procedure creates
7.019583574
value from it, which makes it quite different from the original content;-)

But the solution is very simple of course, I don't care whether it is written nicely or not :roll: , important is content.
So I replaced the getNiceAttr procedure to return directly the value from getAttr and it works fine now.... :lol:

User avatar
metaldev
Orc Shaman
Posts: 761
Joined: Thu Mar 17, 2005 11:56 pm
Location: Boston
x 12
Contact:

Post by metaldev »

hmm... i will look into that, maybe ill get rid of it. as well . :?

thank you so much for doing this dark! :)
please be patient, ill see if i can have a new version out for you soon.

Bringer of Darkness
Halfling
Posts: 98
Joined: Thu May 05, 2005 3:57 pm

Post by Bringer of Darkness »

No problem;-)) - your script helps us a lot, I wouldn't think it is that easy to do only with MEL :lol: , but apparently almost anything is possible to make in MEL.
I would make my own, but I haven't had enough time to go over Maya's API (additionaly it is, well, terribly documented) - and actualy I didn't think that MEL is that powerful :wink:
But apparently it is :D
As for new version - it will come handy of course, although I have made already quite some changes and adaptations in the scripts to our needs, but I guess no problem to transport it.
Thanks for your contributions also 8)

Even though I have problem to get "real absolute" position from within MEL. It seems to me that the real position as is displayed in Maya is stored somewhere I can hardly reach from MEL :evil:

Bringer of Darkness
Halfling
Posts: 98
Joined: Thu May 05, 2005 3:57 pm

Post by Bringer of Darkness »

Okay, I have finally solved the f$%#$ Maya's object position madness :lol:
Searching via different forums and discussions I have found several with the similar problems - once the transformation on the object is frozen, our request via xform or getAttr will NOT return the actual correct position of the object. It is the most probably stored somewhere deep inside the Maya nodes, but I have found no way how to access that.
So I created a weird, but working solution:
1. Create a locator, at 0,0,0
2. Point constrain it to the object we want position from
3. Get the position of the locator
4. delete the locator.
The position of the locator IS correct position in world space.

Script can look something like:

string $tempLokator[] = `spaceLocator -p 0 0 0`;
pointConstraint -offset 0 0 0 -weight 1 $currentObject $tempLokator[0];
float $transformacie[];
$transformacie = `xform -q -t -ws $tempLokator[0]`;
delete $tempLokator[0];

The correct position of the object is stored in $transformacie[] at the end.
Hope it will all work fine for all of you;-))))

User avatar
metaldev
Orc Shaman
Posts: 761
Joined: Thu Mar 17, 2005 11:56 pm
Location: Boston
x 12
Contact:

Post by metaldev »

hmm thats a crazy solution :) ... but i would imagine that it would do the same thing as running the reset tranform script that i wrote or the one that you wrote and then grabbing the object position... no?

Bringer of Darkness
Halfling
Posts: 98
Joined: Thu May 05, 2005 3:57 pm

Post by Bringer of Darkness »

Theoreticaly - yes. In practice - NO :P

This isn't only our problem. The same problem is being discussed for example here
http://www.cgtalk.com/archive/index.php/t-210451.html

and on several other forums I have encountered. In fact xform command doesn't return always the correct values which makes it quite difficult sometimes.
I admit the procedure with creating a locator and getting its transformation is quite a crazy one :wink: , but I haven't figured out any better.

The desription how to create any item, where the xform position will not work is somewhere up there - simply once the transformation is 0,0,0 and object isn't in the centre of coordinate system, it will not return the correct values...

User avatar
the_cX
Halfling
Posts: 77
Joined: Fri Mar 25, 2005 7:13 pm

Post by the_cX »

hey metaldev,
hows the .scene compatibility going? were really looking forward to this....

:D

User avatar
metaldev
Orc Shaman
Posts: 761
Joined: Thu Mar 17, 2005 11:56 pm
Location: Boston
x 12
Contact:

Post by metaldev »

hi cx,


im waiting for my dev teammate to assembe a scene reader so i can test the output of my script... but if someone else wants to lend me their app that loads in a viewable .scene i could get it out sooner. ...either way its coming! :)

User avatar
regress
Halfling
Posts: 78
Joined: Sat Mar 26, 2005 8:39 pm

Post by regress »

metaldev:

if you're like, I can send you the compiled .scene viewer from yake, or you could just download the cvs-snapshot and dependencies and compile away (works without any issues now for VS7.1, linux is being worked on).

the samplesDotScene will simple load up a given .scene and you can fly around to view it.

Here's the instructions for setting it up:
http://www.yake.org/wiki/doku.php?id=qu ... ep-by-step

should be no problem!
regards

User avatar
metaldev
Orc Shaman
Posts: 761
Joined: Thu Mar 17, 2005 11:56 pm
Location: Boston
x 12
Contact:

Post by metaldev »

if you would email it to me compiled that would be awesome! (My profession is 3d art and my c++ skills are still limited.)

thank you so much regress! :o

Niber
Gnoblar
Posts: 4
Joined: Tue Jun 14, 2005 11:53 pm

Post by Niber »

metaldev: Great work this is exactly what OGRE needs, you are making a priceless contribution to the engine with a working scene exporter for Maya.

I'm a Environment Artist that is making a realtime scene in Maya for my portfolio which I would like to export to OGRE, so I would like to beta-test your next version of that exporter.

How about extra functions like these?
1) Multiple textures using alpha-mask to choose between them. For the ground on my nature scene.
2) Overlaying textures, with that I mean like a repetivly highres "noise" texture you can use over you object that overlays the ordenary difuse texture (which gets kind of low-res on close distances) to get extra crisp detail.
3) Mental Ray LightMaps using a second UV for LM's. Ie letting Mental Ray render out the Light Maps instead of OGRE, MR can easily do this its just that few exporters support exporting the LM's UVs.

I don't know if even the engine supports those things at all, since I'm new to OGRE.

User avatar
metaldev
Orc Shaman
Posts: 761
Joined: Thu Mar 17, 2005 11:56 pm
Location: Boston
x 12
Contact:

Post by metaldev »

thank you man,

as far as your requests...
im not sure i understand your first request...

but as far as 2 and 3, (automatically exporting a .material file that utilises detail map and lightmap, is perhaps even already supported - i havent tried it) either way, i believe it is possible.

until then, ogre does support the functionality you're talking about... you can achieve it manually by editing your .material file. tell it to modulate your detail map over your diffuse map.... same for lightmap... you just need to match the correct drawing pass to use the correct UV map in the .material (that is exported by both the native ogre exporter and my scene manager)

Bringer of Darkness
Halfling
Posts: 98
Joined: Thu May 05, 2005 3:57 pm

Post by Bringer of Darkness »

Heya guys,

a brief comment:

>>How about extra functions like these?
>>1) Multiple textures using alpha-mask to choose between them. For the >>ground on my nature scene.

This can be realized via creating a multipass shader (pixel shader) which will use the alpha map as the map. In fact, we have tried to use the similar approach in our other project, but we had used 3 colors instead of 2 in alpha only (it was blending RGB values for 3 textures...).

>>2) Overlaying textures, with that I mean like a repetivly highres "noise" >>texture you can use over you object that overlays the ordenary difuse >>texture (which gets kind of low-res on close distances) to get extra >>crisp detail.

The same as above, it can be reached via either material script or pixel shader...

>>3) Mental Ray LightMaps using a second UV for LM's. Ie letting Mental >>Ray render out the Light Maps instead of OGRE, MR can easily do this >>its just that few exporters support exporting the LM's UVs.

In fact, it works already, we have succesfuly used this approach. Use the following way:
1. Generate MR light map for the object you would like to have (with new UV map)
2. Create new material with layered texture, where one will be basic texture and the other is light map. Assign new material to your object.
3. Either export and edit your .material file to link proper UV mapping to proper texture pass, or link it in Maya and export...

Should work fine...

Niber
Gnoblar
Posts: 4
Joined: Tue Jun 14, 2005 11:53 pm

Post by Niber »

Wow, very interesting, those features would make OGRE engine a perfect choise.

#1 is a bit hard to explain with words, so I've drawn a picture.
Lets say you have 2 textures that is tiled over your terrain, 1 and 2.
1 is the base layer and 2 plus a alpha texture you can make for exampel a path.
Image
The way I've explained here is exactly how FarCry's editor SandBox works, you can use how many layers you want over the terrain.

Now I do not mean dublicating the terrain and add 2 as a new terrain over it which transparency alpha over nr1, that what some guys recommend, but they don't understand how much performence that cost.

When I say terrain I'm not in this case meaning the OGRE terrain system with hieghtmaps and all, I just mean my poly-object on the ground on my Maya scene, that's the way I preferre doing terrain since my terrian is not so big.
Although this feature might be supported on OGRE's real terrain stuff (I have no idea I just started using OGRE) so I could use that instead but I preferre not to since I like to have my whole scene in Maya for extra controll.


Edit:
Bringer of Darkness:
Great, they all work in theory and in the engine, I guess the only question then is if metaldev will make the exporter support these things.
If you (metaldev) would like to include them I could help you out a bit by making test-scenes and maybe make a MEL script that automaticly makes the second UV and MR renders out the LM's.
Although if you are too busy for these things I can respect that.

Bringer of Darkness
Halfling
Posts: 98
Joined: Thu May 05, 2005 3:57 pm

Post by Bringer of Darkness »

>>Great, they all work in theory and in the engine, I guess the only >>question then is if metaldev will make the exporter support these >>things.

Mhm, I guess you only need to setup your material script/pixel shader according to your needs, I am afraid no exporter can help you with this... :roll:

>>If you (metaldev) would like to include them I could help you out a bit >>by making test-scenes and maybe make a MEL script that automaticly >>makes the second UV and MR renders out the LM's.
>>Although if you are too busy for these things I can respect that.

I can hardly imagine any script that would take care of UV generation - you need to correctly create UV mapping non-overlapping and splitted into as few pcs as possible, which is quite much more complicated than realizing via simple script... MR lightmap generation is more or less clicking on two buttons, so I guess any script would be misplaced here as well. Possibly, for combining the MR lightmap together with creating a correct material and assigning it to the terrain would be maybe worthy creating a special script, but well, I am not sure how often you are going to use this lightmap generation so the fastest way so far for a few scenes is to make it by hand...

User avatar
regress
Halfling
Posts: 78
Joined: Sat Mar 26, 2005 8:39 pm

Post by regress »

Ok, here is the YAKE dotScene viewer - I didn't change anything for this release at all, and it's debug, so there! It's 3:00 in the morning, so I'll compie a bit nicer one today or tomorrow, and add rotating with the mouse - but it'd be great if someone wanted to step in and add the features to yake/yapp!

Also, this ogre is 1.0RC I believe, so there may be some features lacking, we'll see.

Change hxxp to http:

Code: Select all

hxxp://www.specialvideosales.com/dotScene.rar
If you see anything you'd like to be added, let me know, or you can always add it as well :D
regards

Post Reply