I just made this little flowchart to wrap my head around the framework concept and how it would provide the smoothest user experience.

Basically, all we do is "outsourcing" the user interface.

A wrapper script should start the sIBL GUI by firing a commandline call and putting the host app into a listening mode. That's the first handshake. If necessary, you might put the 3d app into wait mode, or at least suppress any subsequent calls to the wrapper script.

The second handshake is when sIBL GUI is done. Then your wrapper grabs and executes the setup script. Done.

However, I would like to add that I probably won't switch the Lightwave script to the framework anytime soon. The UI is just fine now, what I struggle with is the actual setup part. Lscript gives me crazy flexibility for low-level UI creation, but the Lightwave it runs in is such an old codebase where many things are still hardcoded and not exposed to scripts. There is no series of scripting commands to fire, I have to manually edit the scene in text mode, which is extremely context-sensitive.

I was away from this forum for some time and i missed this great thread! It's a wonderfull idea to work on a framework, because this would make it more easier to have a real plattform independend loader.

Hello Dschaga o/

Yeah :]

After I have a stable enough and working thing, I'll look toward creating Templates for others softwares, even simple ones or even make available different templates for different renderers, like some for Maxwell, Fry Render, or 3Delight in XSI or Maya for example.

Quote:

This would give us also the opportunity to work on strategies to weld/glue 3d applications and the different scripts together.

The idea ..if i have understand it correct... that the loader can generate a valid script for different 3d applications is brilliant, because if this works, we can think of writing more scripts that way. We only have to find an easy way where the usability isn't broken, because it means that the user executes a script which starts the python thingie, which then generates a valid script which then have to also to be executed. ..so this seems to be the most difficult part ( IMHO )

Currently It's basically a matter of 3 clicks on XSI: one to Launch sIBL_GUI (that the same you would do to launch an internal interface), another one to outpout the loader script ( this is the one that is added :] ), and a last one to import the loader script :]

In next releases, I'll add a direct connection to packages that accept socket connections, like Maya and XSI, so you will just have to click "Send To Software" in sIBL_GUI (this remind me that I need to add a widget for the port in the interface) and you should be ok :]

I hope i have time next week to look into a 3dsmax template.It should always be time to create a proof of concept ...attached a template for the scanline renderer (even if it makes no sense without GI) [/quote]

I didn't tried the template but it should work like a charm with the current version of sIBL_Framework (It will not with the next release because I added another attribute to the Templates, should take 30 secs to fix :] )

Quote:

One suggestion for the framework:There is a framework, so we could calculate the 3D coords of the SUN inside the framework.

It should be doable yeah, Currently I'm not doing any maths in the Maya and XSI templates : I'm using some Surface/PointOnSurfaceInfos Constraints to stick the sun at the correct U and V position on the Feedback Sphere, so it's exactly where it was positionned in sIBLedit, dunno if this kind of stuff exist in Lightwave and max. I wanted to make the framework blind to any kind of scene processing stuff, but if you think that the sun maths can/should be calculated in it, it can be :]

I just made this little flowchart to wrap my head around the framework concept and how it would provide the smoothest user experience.

Basically, all we do is "outsourcing" the user interface.

A wrapper script should start the sIBL GUI by firing a commandline call and putting the host app into a listening mode. That's the first handshake. If necessary, you might put the 3d app into wait mode, or at least suppress any subsequent calls to the wrapper script.

The second handshake is when sIBL GUI is done. Then your wrapper grabs and executes the setup script. Done.

I think it's currently working like this on XSI :] It will be even better when the straight connection will be coded.

However, I would like to add that I probably won't switch the Lightwave script to the framework anytime soon. The UI is just fine now, what I struggle with is the actual setup part. Lscript gives me crazy flexibility for low-level UI creation, but the Lightwave it runs in is such an old codebase where many things are still hardcoded and not exposed to scripts. There is no series of scripting commands to fire, I have to manually edit the scene in text mode, which is extremely context-sensitive.

Blochi

Oh yeah of course, the goal is not to replace any existing loader script. Even If I have a Maya template, I'm not planning to release a Maya specific version of sIBL_GUI ( I may do it for specific rendering engines if there is the need and volXen don't have time to improve his script to support them, but currently his loader is doing the job fine, and I'm using it :]] ). I just want to provide Smart IBL awareness to 3D packages that don't have it !

To be honest: The small snipplets doesn't work on my system (ImportError: No module named win32com.client ..dunno why) , but this could work on all apps which offers OLE automation and seems to be pretty easy to implement.

It could work that way:1. We start our script in the 3d app, which then loads the function which waits for the call from the python GUI.2. The script starts the python GUI3. The user can choose the sibl inside the python GUI4. The python GUI generates the script from the template5. then it broadcast the call over the OLE communication 6. the script inside our 3d app will execute the called function to run the generated scripts7. ..the python gui still can be open and sends another calls if the user loads a different sibl ..8. when the pythonGUI closes, it sends a call to the script inside the 3d application to quit this script too.

..well ..could work, but this is only working in windows - are ther any alternatives?What are socket connections?

I'll need to get a 3dsmax version to test this :] A socket connection is this (definition provided by googling) : "A socket is a software endpoint that establishes bidirectional communication between a server program and one or more client programs. The socket associates the server program with a specific hardware port on the machine where it runs so any client program anywhere in the network with a socket associated with that same port can communicate with the server program."

Basically you open a port on the target application, the application will listen wha'ts currently getting feeded through the port. You can remote control your application like this, it's working like a charm on Maya and XSI, I don't have a clue with Max.

By the way I'm glad to say that sIBL_GUI 0.9.0 is released with the associated XSI 7.0 Addon :] Don't hesitate to test the application and give me feedback if you find bugs, not working stuff etc :]

I have a problem adding my sIbl collection folder.When I add a collection with a name and browse to the folder with the subfolders including the sIbl files, it doesn't load the sibl's.Opening the app again is then not possible.

I think you can't open the app anymore because the file settings are written now with the collection path you entered, so it's crashing sIBL_GUI everytime you launch it now. You can delete sIBL_GUI_Settings.rc if you want to restart it. The error seem to be coming from an invalid .ibl file, sound like there is one with a missing "ICOfile Attribute". Would it be possible to try relaunching the application after deleting the .rc file, cancel the new collection wizard, putting the verbose level to Debug and try adding back your collection ? This should show the file that is currently making the app crashing.

ok ...i know the bug: my very first sIBL(/SDR) with an incompatible header ..works fine now!

Ahhh sweet I don't really check the .ibl/.sIBLT file consistency (It's a pain to do, I just prey for them to be ok :] ). I released an update to correct the Log Window behavior. It was currently keepeing refreshing.

Quote:

I also had some problems opening the app with additional files in the template folder(zip-file).

I'll check my templates folder parser to only read .sIBLT files.

For the Renderer thing : you mean you would prefer have an attribute of the template shown in the template dropbox (like the renderer) instead of the template name ? It should be easy to do and sounds really good! I just realised that we will have a problem if we have two XSI scripts for Mental ray for example, using an attribute in the template file like Renderer = Mental Ray, we are not sure of the uniqueness of this attribute along the templates.

By the way, I just checked my templates folder parsing code, pretty crappy at some point, it was a copy paste of my Collection Class and I did forget to check it was adapted for the Templates, I'll update it

If you wanna contact me on MSN directly, you have my adress everywhere (Templates, sIBL_GUI), On skype my contact is ksolaar, but I don't have a mic currently.

I let you two battle this out... just a quick feature request in-between: Since you know the datatype of additional attributes from the template definition, it would be nicer to present booleans as checkboxes.

Quote:

h and Christian : Do you mind if I over use your Light Bulb Icon ???

Don't mind at all, it's actually much appreciated. I've attached a PSD with all matching icons, feel free to use them... makes good branding for the whole Smart IBL suite.

Oh, one more thing: Not sure if a true socket connection is necessary. In Lightwave, when I spawn an external program in a commandline, I can have the script listen to the returning commandline output.... not sure about MAX, but that would be a good way for notifications.