LuxStudio...

[rendermagic]

I thought about your comment rendermagic about being cross-renderer compatible but I must admit while it is appealing it can create a lot of headaches when it comes to incompatible features. Ever tried to choose a movie with more than 3 people? I'd suggest we focus on lux atm however it might provide an interesting template for other FOSS projects to use.

Good point. I didn't think of that. We should definitely focus on Lux atm and if it's not to difficult or resource draining, make it a little easier for other FOSS developers jump on the train. Ultimately, the Lux devs should focus on Lux goals first and foremost.

[Carbonflux]

This has been a great discussion

I think there is enough to distill a requirements set for a prototype.

My interpretation of this is a first pass at a prototype for LuxStudio should include the following:

A basic Qt UI environment.

Loading and saving a luxrender scene. This is the most problematic part and might require hacks that break the luxapi boundary in terms of getting access to the scene geometry or duplication of core code, at the same time this will provide information about how api changes should be implemented.

Being able to import wave front objects.

Displaying a luxrender scene in opengl and altering the position and rotation of objects and lights.

Once this is working the next step will be build up a node interface for materials, the idea of integrating python should be explored because it would be nice to leverage the work dougal has already done on this, unless its better to just redo it in C++/Qt.

The biggest awkward element is that to get a prototype working there might have to be a lot of code duplicated from the core however this can be a wrapped in a way that will make it easy to replace with expanded api calls.

These are just my reactions to the discussion so far. I plan to at least start sketching this out in Qt this coming week if possible.

[Pilchard123]

Why would loading/saving a Luxrender scene be problematic? I'd have thought that would be the easiest part. Lux currently has to be able to load a scene, and the exporters save one. Couldn't the same principle apply here?

[dougal2]

Once this is working the next step will be build up a node interface for materials, the idea of integrating python should be explored because it would be nice to leverage the work dougal has already done on this, unless its better to just redo it in C++/Qt.

I have found when writing the material editor prototype that using pylux as a bridge between two C++ APIs simply doesn't work - and that is why I built the C++ dll interface in the cpp_api/ folder of the lux source tree. It is the pure C++ equivalent of pylux, and has been proven to work in my prototype.

If you're serious about using Qt and a dll interface, I'd seriously suggest you look at what I wrote before, even as a guide or reference on how to interface with Lux through the dll.
[ref: https://bitbucket.org/doughammond/luxre ... elpers.cpp ]

[BTW, the cpp_api/ isn't only for dll on windows, it will also build to the equivalent shared library on linux; it is a cross-platform solution]

[Carbonflux]

I'd have thought that would be the easiest part. Lux currently has to be able to load a scene, and the exporters save one. Couldn't the same principle apply here?

The real issue is the formalism of C/C++, the "core" of lux is built as a lib and compartmentalized so that all access to this functionality is being passed thru a formal API when called from a GUI, what is problematic about this is it might be necessary at first to duplicate some of this code in the GUI which is a huge violation of compartmentalization and the idea of reusable code, both ideas being very important in terms of application programming for very good reasons, once you violate compartmentalization you incur a maintenance problem which only grows over time.

If you're serious about using Qt and a dll interface, I'd seriously suggest you look at what I wrote before, even as a guide or reference on how to interface with Lux through the dll.

I admit I am more serious about this than normal, losing the work you did would be a mistake imho, I plan on going out of my way to leverage and reuse as much as possible.

[jeanphi]

Hi,

Interesting discussion. I agree with the point that relations with Blender should be improved, however Blender directions are not the only point making a studio interface attractive like Lord Crc reminded.
This is actually an interesting shift from core features to usability. However we really need to straighten out our API to make this viable. A studio interface will really need to communicate with the core on a finegrained scale so core objects should accessible both for reading and writing. This was the purpose of the queryable API, unfortunately we only scratched the surface there. Going further is IMHO a necessary first step to allow building a more advanced GUI than the current one.

Jeanphi

[Carbonflux]

After talking with LordCrc tonight in IRC I think I have a even more well defined model of how to move forward with this.

Creating a new dir in the lux source main branch called luxstudio which will function as a prototype. It will be another version of the luxrender UI using Qt. One main goal is to not effect the core lux lib which I think this model satisfies.

Luxstudio will be able to import mesh files, wave front objects and hopefully luxrender meshes and display them using initially opengl but with a render engine abstracted beyond a specific platform.

It will be able to export luxrender scenes but have its own luxstudio file format based on xml right now and storing the scene as a tree structure. The argument being that the lux scene format is not really a transportable format. Part of the idea is that exporters can read the luxstudio file to resync the positions of objects, lights and the camera.

The value of this is it will allow the luxstudio prototype to be developed without waiting for api changes but when api changes are implemented they can be incorporated easily. Also it will support the development of a mesh handling sub-section in the GUI which can evolve into a separate mesh handling lib.

So the introduction of luxstudio will have very little if any impact on the core but at the same time lay the groundwork for expansion of the api when time allows and also support experimentation with different compartmentalization models.

[rendermagic]

I think that's a great idea Carbon. You and lord have put together a really good road map. I think it will serve both existing and future Lux users nicely.

[paco]

Sounds good to me

[dshihlai]

Hi! Everyone, first time here:

Actually now there are couple FOSS solution to the animation problems:

1. Alembic: an open source format for animation cache/export/baking. Basically once you are done with the animation the animator bake-out the animation data along with base geometry on a per vertex basis, without any other complex, procedural data attached:

http://www.alembic.io/

I think the Alembic is way to go for this kind of workflow for the say studio app.

As a demo of the idea of a lighting studio app you can checkout Foundry's (previously Sony Imagework's) Katana:

http://www.thefoundry.co.uk/products/katana/