(Re)Implement LuxMaya as python scripted plugin

[dougal2]

This evening I checked out the existing exporter source, had no end of trouble compiling it, and eventually managed to crash Maya when loading it.
Basically, nothing really worked, and I'm not really surprised as I imagine that my platform is quite different from the one used to write the plugin.
(I'm on vista 64 bit with Maya 2008(64bit) and VS2005).

So, given that c++ binary plugins are
a) - OS specific
b) - Maya version specific
c) - apparently not easy to compile for different versions and platforms,
I'd like to suggest that the exporter be ported to python for use as a scripted plugin.

I can see some pros and cons already:
a) + it's cross platform
b) + it doesn't need compiling
c) + the entire Maya API is still available
d) + the existing c++ code can be translated fairly easily
//
e) - It'll take a little bit of work to do (although nothing particularly "new" or radically different has to be written)
f) - It'll only work on Maya 8.5 and greater

I have a little experience with crafting python plugins for Maya (I did a shader node for Indigo), I can help -- indeed I may go ahead and translate the existing exporter anyway just to get more familiar with python in general.

However, I'd like the approval and the input of the exporter authors first. I know it's "free", but it's still your code

What do you think?

[dco]

Hi dougal2, first welcome aboard and thanks for your proposal.
I'm happy to see a much more experimented dev than me here, as i mention it somewhere i'm a dummy programmer, so it's easy to do better work than me, and i know the great job you're doing for maya to indigo !!

As for your Re(implement) job, it is one of my first idea, i still prefer python than c++, but as i have not enough free time to coding, i just took some time to re-arrange the code initially developed for PBRT (aka Maya-Pbrt from Mark Colbert) and it was first for my own usage, but Radiance asked for me to get enrolled here, so i try to do some minor addons in materials part, but it my first time trying to get into the Maya API and it very different than my knowledge with python command, so i start from scratch, now here we are, and as you said it will be better to have a non-os specific exporter and python is very robust with large dataset.

I think it will be a good idea to mantain the name, perhaps you just need to create a new topic like LuxMaya (Python), and a TODO topic associated, there are also a bugtracking system that can be used here (mantis).

Thanks for your time,
dco

[NextDesign]

I've been working on a MEL version for a while now. I'm using MEL as it can also be used by version of Maya lower than 2008. Right now I have all the information loaded, and a complete scene file exporter. The only thing I'm waiting for is a file specification for the mesh file format.

[dougal2]

can lux load .obj files? MayaToIndigo uses the OBJExporter plugin, and I've got tried and tested routines for exporting visible objects as .obj.

I've started translating the c++ into python.
I've got the plugin loader working, and have started on luxview() for loading .tga files into the renderview.

I've got it to parse and load .tga files without problem, but I'm having issues passing the pixel data to MRenderView.updatePixels()
Porbably the problem is that I can't find any reference at all for the RV_PIXEL data type, and making an RV_PIXEL class in python

Code: Select all

class RV_PIXEL:
   r = 0
   g = 0
   b = 0
   a = 0


and passing that to Maya doesn't work.

On the other hand, all the luxview class seems to do is load a .tga file into the RenderView - perhaps there's another much simpler way to display the image instead? (launch fcheck ?)

EDIT: I've changed it to launch fcheck instead. (reduced 160+ lines of code into 4 ) I'm not sure if this makes sense in terms of the exporter's execution yet, but I guess I'll find out when it's complete

[dco]

Hi,

@NextDesign: Happy to see there are an increasing interest for developping an exporter for maya, so welcome aboard too
For your problem for the mesh file format, you can check in the actual LuxMaya (c++) code to get an idea of the way the mesh exporter work.

@dougal2: Good you already started to work on this, for the OBJ loader in lux, for now it's no way, but it can in a near feature be an option, Radiance doesn't answer for that actually, personnaly i use a custom cvs built that load obj file based on this plugin for PBRT on Mark Colbert page (http://www.cs.ucf.edu/~colbert/mayapbrt/goodies.html), but it do not support for multi material meshs so pretty incomplete for now.

For the RV_PIXEL structure, you can see a good usage exemple in the demo plugin "renderViewRenderCmd" in the devkit.

Cheers,
dco

[dougal2]

The examples for renderView in the devkit are in c++, and read pretty much the same as the current exporter. I still cannot find any documentation for RV_PIXEL, I don't know if it exists in the python API for Maya.
I don't think it's a problem for now though, I've got the image to load in fcheck instead of the render window.

I've also renamed launchlux to luxlaunch in my plugin, and that's working now.
(the functions are now consistantly named lux* )

Now for the real hard work of actually starting to translate the exporter script....

[dco]

I can't help much but fcheck it's a good alternative too, there are imf_disp that is smaller and faster to load also if you look for efficiency.

Good luck !!

[dougal2]

ha! I just found it through guesswork

Code: Select all

pixels = maya.OpenMayaRender.RV_PIXEL


pretty obvious really

EDIT: Success! I've loaded a .tga into the renderView!
I've left in the code to launch fcheck, and added a switch to change between the 2 display methods - let the user decide

[dougal2]

first "real data" output

Code: Select all

LookAt 1.73649578799 8.76586062154 7.85536623486 2.15383266777e-014 1.42108547152e-014 9.85878045867e-014 -0.12829596697 -0.647640249142 0.751067408793
Camera "perspective"
   "float fov" [86.3900370247]
   "float focaldistance" [11.8980044016]
   "float lensradius" [0.0]

Film "multiimage"
   "integer xresolution" [600]
   "integer yresolution" [600]
   "string ldr_filename" ["test.tga"]
   "string tonemapper" ["reinhard"]
      "float reinhard_prescale" [1.0]
      "float reinhard_postscale" [1.0]
      "float reinhard_burn" [1.0]
   "float gamma" [2.2]
   "float dither" [0.0]

PixelFilter "mitchell"
   "float xwidth" [2]
   "float ywidth" [2]

Sampler "halton"
   "string pixelsampler" ["vegas"]
   "integer pixelsamples" [4]

SurfaceIntegrator "path"
   "bool metropolis" ["true"]

Accelerator "kdtree"


LookAt, fov and focaldistance is all real data from Maya's camera

A lot of (erm, acutally, ALL) the render settings are hard coded at present. I was wondering what strategy we could use to set these?
The best solution that I can think of (as it's a very familiar concept with me already ) is to have a rendersettings scriptnode like MayaToIndigo.
Can anyone think of a better way to do it ?

[Radiance]

hi guys,

good work

as you might have read in the announcements forum,
ratow is now going to be coordinator all development of exporters.

it's becomming very difficult for me to keep my eyes in this area
and answer your questions as i've currently 1000's of other things
to do in the engine development areas.

feel free to ask ratow about your needs.

we're going to be working on the scenefile docos and other documentation
you'll need for your exporter.

one thing though is that you should 'all 3 of you' work together,
instead of different exporters.

i'm not very up to date on things,
but i'm also thinking the python exporter should be the best option
in regards to speed and easy of coding.

i've heard before that MEL is too slow, and i can see that not many
exporter devs can be fluent in C++.

however that's just my stupid opinion as i don't know bout maya

I suggest you all settle on 1 idea and join hands on 1 good implementation in python,
and use our CVS effectiveley for group development.

please ask ratow if you have any questions,
and we can also get you CVS accounts if needed.

greetz,
radiance