(Re)Implement LuxMaya as python scripted plugin

[dougal2]

Personally I think that Python is the best solution too. However, I didn't come here to enforce my view on others.

From a pesonal point of view, I'm doing my python bit mainly to learn python (and more about the innards of Maya) - and I intend to keep my code to myself until the other Maya exporter devs say that they want to go one way or another with the exporter. I'm not fussed if my exporter doesn't become the official one.

BTW, my plans for my Python based Maya exporter is to first do a complete translation of the c++ exporter - regardless of functionality that's missing/wrong/out of date etc.
Hopefully by then I'll understand the language enough to be able to extend the exporter's functionality, and there'll be enough documentation to be able to implement new features correctly.

I'm happy to leave the decision with the existing devs here, after all I'm the new guy

[dougal2]

I have spot and point lights exporting now.
Although, the spotlight output is not what I expected at all. Why is there no light in the centre of the cone?

Code: Select all

TransformBegin
   ConcatTransform [0.957826285221 0.287347885566 0.0 0.0
                    -0.198762688608 0.662542295359 0.722171101941 0.0
                    0.20751433916 -0.691714463866 0.691714463866 0.0
                    3.0 -10.0 10.0 1.0]
   LightSource "spot"
      "color I" [0.0 1.0 1.0]
      "point from" [0 0 0]
      "point to" [0 0 -1]
      "float coneangle" [45.0]
      "float conedeltaangle" [0.0]
TransformEnd


[dco]

Hi, lots of progress here, you work fast. As for your question about render settings, i've tested the method you use for MayatoIndigo and it work fine, my intend for the c++ plugin was to be seamless as possible with a standard maya use, but integrating a good render setting in the mel part of the code was a bit frustrating for me, but i recently found a way to get thing done with c++ and minimal initialize code in mel, but again scriptnode version work just fine, as you i am learning both c++ and python.

For the spot problem, in fact there no prob, after testing the spot light myself from the exporter, i can see nothing goes wrong, but in your picture the dark is simply the luxball shadow.

And about the sampler, could u change "halton" to "lowdiscrepancy", it an error of me when i was testing thing in pre-RC4 phase.

@Radiance: Yup, i agree with the fact we need to join our force to provide something strong, i work less than before on the exporter, but i can still help in some area, we can discuss on this in the next irc meetings if all can attend.

Cheers
dco

PS: Here a test render with 2 spot and dropoff about 70

[dougal2]

ah shadow. yes of course. I guess i didn't expect the shadow to be quite so "total".
Anyway, I've made fairly quick progress due to the fact that translating from c++ to python is really quite easy.
example:

C++

Code: Select all

// loop through all the lights
MItDag lightItDag(MItDag::kDepthFirst, MFn::kLight, &status);
for (; !lightItDag.isDone(); lightItDag.next()) {
   lightItDag.getPath(tempDagPath);
   
   // visibility test
   MFnDagNode visTest(tempDagPath);
   if (isVisible(visTest)) {
      Light* light = Light::LightFactory(tempDagPath);
      if (light) {
         fout << *light << endl;
         delete light;
      }
   }
}


Python:

Code: Select all

# loop though lights
lightItDag = OpenMaya.MItDag(OpenMaya.MItDag.kDepthFirst, OpenMaya.MFn.kLight)
while not lightItDag.isDone():
   lightItDag.getPath(tempDagPath)
   
   visTest = OpenMaya.MFnDagNode(tempDagPath)
   if self.isVisible(visTest):
      light = LuxModuleLight.Light.LightFactory(tempDagPath)
      self.dprint( "Found light: " )
      self.dprint( light.loadLight() )
      self.dprint( "-------------" )
      if not self.debug:
         light.writeLight( fout )
   lightItDag.next()


( i have in fact added a little bit of extra debug output with my self.dprint() function, and I turn off file output when debugging. Essentially I can switch between just printing the output in Maya's output window, or writing a file ).

I've still got the major task of translating the mesh and materials classes though. I shouldn't think that'll be done as quick, especially as I'm going on holiday next week

Perhaps it'd be a good idea for me to make my python code available before I go away in case anyone is interested?
(this is completely contrary to what I said about 3 posts ago, but hey I don't really mind)

[Ratow]

Hey dougal2,

You been doing some good progress indeed. Please do make your code available so that everyone can analyze it and play with it.

Personally, I love python and its flexibility, so I may be a bit biased.

-Ratow

[NextDesign]

The only problem I have with python is that only users of Maya 8.5+ can use it, thus limiting (by a lot) your users. I really think it would be the best way to do things.

[Radiance]

Hey,

a pointlightsource (aka all lightsources besides an emitter) have no geometry.

they are thus infinateley small, and are so called 'delta' functions.

they can only be sampled at points but cannot be found by a path trough geometry,
resulting in this behaviour.

(it's also the reason why sunlight does'nt work trough glass yet (something pointed out between maxwell and indigo before). )

we need to make some changes to get the sunlight to work trough glass,
and also delta functions

i suggest you focus on mesh emitters for now

greetz,
radiance

[Radiance]

viewtopic.php?f=27&t=510



Hi guys,

before you all start coding your exporter(s) ,
i suggest we first plan things accordingly.

having different people code different exporters is not only a waste of time, resources,
but also results in confusion for users, as well as unnecessary competition between developers,
which is absurd in a GPL environment.

i would like to propose that you all read my post here first:
viewtopic.php?f=27&t=510

and comment/work on the idea.

it would make sense to merge the efforts into 1 exporter for all apps,
with hooks to the app in question,
and also eliminating the need for hardcoding options, parameters and stuff in each exporter.

i think working in this way with a python maya dynamic exporter, in CVS, which cannot
be adandoned or desynchronize if the developer of it is away is it the way to go.

anyways, i'm leaving ratow to further organize things :p

greetz,
radiance

[dougal2]

OK, here's my current progress.

This plugin is currently pretty much NON FUNCTIONAL. It'll load and register 3 new MEL commands for Maya:
luxexport
luxview
luxlaunch

But they're not tied togehter yet and don't really produce correct output. You'll have to run them by hand with the correct parameters to see the results of what I've achieved so far. Don't expect anything to really work. Especially luxexport, I've done a chunk of work on it last night and not finished or tested it yet.

If anyone goes ahead and works on this, bear in mind that I'm pretty much method-for-method copying the C++ exporter currently, and it has been my intention to keep this as close to the c++ implementation until they are essentially the same, and then go over the code and extend or refactor as necessary.
Already though there are a few syntactical changes where necessary and I've renamed a few methods, but it basically is the same approach.

I'm going offline for a week as of tomorrow, so have fun with this and I'll catch up with you all when I get back.

[dougal2]

3 downloads... did anyone do any further development on this?

If I'm honest, I've not much time or use for lux at the minute, so don't have much motivation to finish what I started here.
Perhaps later this year my work-focus may change a little and I'll be willing to put more time in.