Maxigo 2.0.12a (updated on 17.oct 2009)

[suvakas]

thnx a lot suv!!!

Hey Kosmo,
It's been a long time since I saw you around here.
What have you been up to lately ?

[losbellos]

Hej Suvsakas, how is life? I see your exporter is progressing nicely.
Here are some ideas for you, that might make it better.

hdri enviroment mapping type selector button, spherical, longitute latitude etc, and rotation x y button, and have an option to see it in the viewport as well (or use max's enviroment, with the offsets) thats also kinda easier.
camera doesnt match withe the max cameras, there is a cropping. I double checked the resolution it was the same.
Get the region render setup from max's region render, why do you make your own? Less work for you. And because of maxscript the other might be more stable
Geometry export: in my opinion Use backgorund worker instead, so that you can output the geometry in more than one task, this way it will be faster. At least two, or more. About 50% percent gain with an other core. Unfourtunately not 100%, with better programming probably it can increase to 60-75%. I didnt have at the time quad core, but maybe one day I will try and see.

[suvakas]

Hey losbellos,
I'm doing fine, thanks.

Get the region render setup from max's region render, why do you make your own?

I couldn't find a way how to access the native region parameters from maxscript.

Geometry export: in my opinion Use backgorund worker instead, so that you can output the geometry in more than one task, this way it will be faster. At least two, or more. About 50% percent gain with an other core. Unfourtunately not 100%, with better programming probably it can increase to 60-75%. I didnt have at the time quad core, but maybe one day I will try and see.

.Net support in Max 9 has quite big issues. Global variables for example..and stuff like that. It can get very messy to implement something like this and I'm not sure it would work. Have you implemented something like this yourself or is it just your theory? I will convert the geometry export over to C++ anyway.. one day

camera doesnt match withe the max cameras, there is a cropping.

What cropping? For me the camera seems to match perfectly. See the image.

[losbellos]

Yes, I have an implemented version and I have a working cropper as well. I will look into my code and send it to you. Or I just pass you the code.
for the region : renderRegion = viewport.getRegionRect 1

[losbellos]

Unzin and run, uncheck the export material option (otherwise it will ask for a differerent code). If you want to test the speed with one core, find in the code the cpunr variable and set it to one, and execute the code again, and then render. Dont forget to set the path where files should point. The speed gain is about 50-60 percent with one more core. Right now it will work with maximum 2

Your exporter works with the same effeciency as mine, 1.1 million polygon, takes about 90 sec to export, with 2 core it was only 53 sec... Its very easy to implement and this way max doesnt hang while exporting it. So one can do other taks as well. You may also check this website. http://lonerobot.net/?p=50

[suvakas]

Interesting. Thank you losbellos, I'll check out the code.

About the region rendering.
I wanted to have full control over it and not just read values. I wanted user to be able to define a region from Maxigo panel. I couldn't find a way how to force Max into region drawing mode from script.

In order to use a built-in region user would have to :
a) Set render type to "Region" from Max toolbar
b) Open up the renderer panel (F10)
c) hit Render to define a region
d) Open up the Maxigo panel
e) Pick Region for rendering mode.

Way too messy and not very logical if you ask me. I think there was a topic about it on the forum too.
With my custom region script you can click "Draw region" button and switch rendering type to "Region". A bit more straight forward approach.
BUT, i now got an idea, that there could be an extra option like "Use Max region" or smth like that. That way users can pick what method is better for them.

[losbellos]

I think it shouldnt be that hard to do the region render from maxscript, because you can set in the common panel to region through maxscript, and so on, Maybe even possible to start the region render. Some info are well hided in the help file, sometimes it took me days to figure out, but it is workth I will check the camera again, and send you the file if there is any problem with it.

[suvakas]

Yeah, there are tons of "hidden" stuff inside the help files.

[losbellos]

just for ya,
EditRenderRegion.EditRegion()
and
viewport.setRegionRect <viewport index> <box2>
Set the region rectangle for the specified viewport.

viewport.getRegionRect <viewport index>
Get the region rectangle for the specified viewport.

Of course its upt to you, but this might be the best for people. Otherwise your region drawing is fantastic, I like it, only that it is not resizable.

[losbellos]

It will be beneficial to use only two cores, export time with four cores is almost the same as with two. Could be that there is some programming error, but bobo said someting about sharing the same memory and execution path, thats why it doesnt work more effeciently with more cores. But this 50 percent is valuable to implement. Will see. I will spend some time on it when I will have.

[psor]

Suv, first I wanna thank you again for your awesome work on the 3dsmax exporter. It is a very
fine piece of scripting you've done so far. I've found a small bug that was bugging me for a while,
but I couldn't reproduce it so I haven't reported it yet. I haven't had time anyway.


So today I was using 2.2.6 to play with it again and the bug came up again ... *Aaaargh*


What I'm doing basically is that I'm creating an object use a diffuse material on it and let
it emit light. The material is called "emitter". What happens is that Indigo starts up and pops
up an error that says it can't find material "emitter1". Ok, checking the xml for the materials
found a material called "260emitter1" copied it and changed it to "emitter1". Indigo is still
popping up the same error. Then I found the name "emitter1" in the xml for the scene right
in the <model> for the emitter. After I've changed the name "emitter1" to "260emitter1"
everything went right and Indigo started rendering.


The weird thing is that I had errors like that in the past but also with materials that haven't
been used as emitter. Maybe it where blended materials tho, I dunno anymore. It did make
me sick and I had no time to spend on those issues. I'll try to be more supportive in the future.


Some quick questions for you. Is it really needed to change the name of the material that gets
exported from max? If so what's the purpose of doing it? Is it really needed to export the same
material for every object even if it is the same? I don't see the purpose for this yet.


Two more things. I'd like to see the linear tone mapping as option too. And I'd like to see
the possibility to change the environment mapping (latlong/spherical) too.


Thanks for your time and keep it up!


edit: I knew I would forget something. I miss the settings for the unit when it comes to
the emission. Right now you just support "luminance". So it's missing an option to use
Luminous Emittance (lux), Luminous Intensity (cd) and Luminous Flux (lm). Please make
it possible to use them too.

edit: I've found another bug. If a material is using emission and the layer is set to 1
then it is set to zero in the xml and thus it will be on the same layer like an environment
map for example. So please change that. Thanks!









take care
psor

[suvakas]

Thank you psor for the feedback.

Unfortunately I can't reproduce this emitter error you are having. Maybe you can send me the Max scene?
The reason behind renaming materials is, that inside Max different materials can share the same name. For example make a Multi-Material and rename all the sub-materials to "blah". Then copy this material and you have 20 different materials named "blah". Now if I would export a material named "blah", then instead of 20 different materials we would get only 1 "blah" in Indigo. To avoid it I'm constructing a new material name like this: model id + material name (non-ascii chars removed) + mat. index. The drawback of this system is, that I have to export material separately for each model cause the model id is different for each model. Does it makes any sence?
Sometimes Max doesn't return a correct model id and I think this could be the cause of the problem you were having with the emitter material.

There are ways to implement a better system, but that needs a C++ code. I have it in my to-do list already.
Ps. Will add your other requests to my list too

[suvakas]

edit: I've found another bug. If a material is using emission and the layer is set to 1
then it is set to zero in the xml and thus it will be on the same layer like an environment
map for example. So please change that. Thanks!

That seems like a normal behaviour to me.
There is no "zero" layer in Max. Layer counting is starting from layer 1.
I thought it's a bit strange to have a "zero" layer, but apparently this can be confusing?

[edit]
So everything that is on layer 1 inside Max will go to layer 0 in Indigo.

[psor]

Thanks, that makes sense. I was getting annoyed by it sometimes because I tend to edit
the material by hand often and then I've to change it more times then I want to ... haha.
Ok, so I'll live with it right now. The scene with the issue is attached to this post.


Yes, the layer thing is confusing cause I can't set the layer for the environment and so
I thought if I set the emission to 1 then everything should be cool. I was wrong.






take care
psor

[suvakas]

Yes, the layer thing is confusing cause I can't set the layer for the environment and so
I thought if I set the emission to 1 then everything should be cool. I was wrong.

Gotcha, So you think a zero-based counting would be more clear? Should I change it ?

And thanks for the scene. Will check that out asap.