Light Lister V1.0.1

I have rewritten my Light Lister plugin for C4D in python. It can be downloaded here:

Light Lister V1.0.1

It is for C4D V12. It will not work with older versions. Because it is python it should be PC and Mac compatible.

One additional treat…
I have left the source code un-encoded in the file on purpose. At the moment there are so few resources available for learning to program C4D plugins in python that I thought interested parties may learn a few things from the code. Please act responsibly with the source code.

Advertisement

Cinema 4D V12 Plugins Info

I’ve been asked by a few people what will become of my plugins with the release of version 12 of Cinema 4D.

-The batch rename plugins appear to work.

-Ilay Shpilkin on CGTalk was nice enough to compile a version of LightLister for 12, which I will put up here. For now it can be found on this cgtalk thread: http://forums.cgsociety.org/showthread.php?f=47&t=916543&page=1&pp=15

-Destruction will most likely not be developed further by me. Too many other similar plugins out there right now.

-Render Elements will receive an update and some bug fixes, but this will not happen for several months. A lot of things have changed in the SDK and will require some re-writing for this to work.

Light Lister for C4D V11 (Mac only)

Nothing new – just a recompile. Now works in 64bits.

Light Lister

Light Lister Release

Ok, it’s done for now. Time to move on to other things. I really need to finish my texture path tool and, especially, Render Elements before I get back to work.

Downloads here:

Demo movie

Mac Plugin

I learned a few really interesting things making this. One was how to dynamically generate GUI elements. Unfortunately, this can’t be done through a .res file. So, all dialog elements are hard coded into the .cpp file. The way I’ve done it is ok. I’m sure there are better ways. First, I count all the lights in the document, determining the number of dialog rows needed. Then, I go from top to bottom in the object manager, getting all light values and assigning them to the matching rows. I collect the lights’ BaseLinks in a BaseContainer, indexed by row, so index 27, for example, belongs to row 27. When a user interacts with the dialog, all I need to do is figure out what row he’s working with (there’s a ghetto hack I use to do this), then update that light accordingly. Instead of going through the entire document again to find that light, since I have it stored by index in a BaseContainer, I can quickly and easily grab it and update its values.

The other part that was interesting was how to get two different dialogs to work with the same data. I know there are better ways to do it, but I ended up kind of hacking it together (who cares? it works, right?). What I ended up doing was this:

Lister Dialog is the “master” for the light values. Any interaction with the lister supersedes interaction with the object manager. Then, if the dialog detects that it has been defocused (the user is interacting with a different part of the application) control is returned to Cinema, and the dialog is refreshed any time a message is sent from Cinema saying that something has changed. With lots of lights and objects in the scene, the user will probably notice a performance hit, so I would recommend closing the dialog window unless it is really needed. In other words, it should not be docked into the standard layout.