SDK for Connectivity?

It sounds like you're trying to write a visualizer based on the 3DS Max engine, is that an accurate description? Is there any way you can accomplish what you need with one of the supported visualizers, either by modeling in the visualizer directly or importing your 3DS model into a visualizer?

The list of supported visualizers is at:
www.flyingpig.com/support/hog3/downloads/archive/wyg/VisualizerConnectivity.shtml

We do have a module for connecting with 3rd party visualizers at the API level, but it's not publicly available. If you're developing a visualizer, or something similar, get in touch with Brad for more info on the licensing arrangements. It's not something that makes a lot of sense if you're doing this only for your own purposes. If you plan on selling the 3DS Max plugin to a wider audience, it may be worth a discussion

For a quick and dirty solution, you could send DMX out of Hog3PC via a DMX widget, then read it back via something like the OpenDMX USB interface or an Art-Net input box.

Eric’s quite right: the connectivity driver isn’t going to provide much more than real-time DMX stream buffers, so reading in from a Widget really is the best approach to capturing 3PC output on a per-project basis.

However, I’ve found that working with a DMX capture is just a horrible idea:

3PC DMX refresh rate is way too low for NTSC by default, though it can be adjusted.
8-bit integers is all you get. Anything with more than 256 discrete values will cause a need for developing an entire, maintainable “patching system”.
Unless you’re interlacing post, you’ll need to invade the render pipe to get each DMX “frame” to persist/drop mid-field-frame.
Identifying “Frame One” from a DMX capture can be really tricky. You can watch for a dummy cue to bump and have it then fire your first real cue, but then you have to identify the time between the two, etc. There’s always going to be manual work involved in getting things lined up just right.
And most importantly, if you want to make a change, you have to start the entire capture/sync/apply/persist process completely over, making sure everything gets cleaned up and possibly losing any changes made since the last application.
I’ve completely abandoned a project that was meant to light faster in Maya by using 3PC, less like a motion capturing device, and more like a custom modeling environment tool.

As such, the few successes it did have did not incorporate the 3PC playback engine or DMX at all, only the raw cue data saved by 3PC, in all of its type-safe glory.

Using cue data fits very well with the whole concept of keying (as opposed to keying every parameter once per DMX refresh), and it affords you the opportunity to produce a plug-in that’s actually designed to fully participate in the dependency graph [sic]. Linear crossfades should be dead simple to hook up during your XML (hint) import process; all other fades are just a quick lookup in the right CrossfadeTable. You can pull off effects (or better, an entire “keyless” “show”) by employing some simple influencers in your driven keys.

This of course raises the point that a lot of the playback power that 3PC provides will be lost if you choose to forego a finished DMX stream. On the other hand, 3PC’s playback is based upon a human-tuned and rather fixed conception of Time, which doesn’t translate as easliy as one might hope.


A few hints, in general, either way:

Never use pan/tilt. Focusing through a render window blows. always map 3 parameters to “Center of Interest” XYZ
Remember to add parameters to animate “hang position”, too.
Make sure ranges in Fixture Builder match your object limits.
Congratulations, all your fixtures are color calibrated. ish.
A file system watcher is gonna be your best friend for staying seamless.Have fun with this; I wish you well.

Thanks for the replies!

Eric - yes... I suppose in broad terms a visualiser is what I am looking at creating. However, the idea is to take programmed cues and record them to animation channels to be rendered out later (using Mental Ray or V-Ray - I've also been looking at a Maya connection to render using RenderMan), rather than doing real time visualisation.

I suppose you could also say that it is a tool for lighting Max/Maya scenes using 3PC as if I were lighting a real show.

Quinn - thanks very much for the very detailed reply. There is a lot to think about there.

Using cue data fits very well with the whole concept of keying (as opposed to keying every parameter once per DMX refresh)

I agree - it would also get over the issue of DMX refreshing, as long as you could "get" data from the cue such as the length of time a fade / movement should take. That would prove tricky however for any movement that was not linear...

Never use pan/tilt. Focusing through a render window blows. always map 3 parameters to “Center of Interest” XYZ

Excuse my ignorance. By that do you mean that the spotlight (or whatever kind of Max/Maya/V-Ray/finalRender light it is) should always be set to "look at" a dummy object/helper and it is that helper which is animated, rather than the light itself?

Remember to add parameters to animate “hang position”, too.

As part of the project, I plan on creating a library of fixtures, which are then inserted by a single button or menu click (the fixture geometry and the max/maya light will be created using a MaxScript/MELScript). onClick, a UI will pop up asking for hanging position.

Perhaps it would be easier to create a simple(ish) UI inside the 3D app (or using the .NET connection in the latest Max) which emulates as closely as possible all the relevant 3PC functions. Then all(!) I would need is to write a file translator which reads 3PC cues and converts them into a format that Max/Maya can understand (probably using XML as the middleman).

Cheers,

Martin

[quote=FirmamentFX]I agree - it would also get over the issue of DMX refreshing, as long as you could "get" data from the cue such as the length of time a fade / movement should take. That would prove tricky however for any movement that was not linear...
[code]


2000


0


1




2000


0


1


[/code]
again, you can define your nonlinear curves by translating the appropriate CrossfadeTable.


[quote=FirmamentFX]Excuse my ignorance. By that do you mean that the spotlight (or whatever kind of Max/Maya/V-Ray/finalRender light it is) should always be set to "look at" a dummy object/helper and it is that helper which is animated, rather than the light itself?
yes, if you're focusing from the console, it's best to provide absolute coordinates to a light's "look at" parameters rather than rotating the actual light object by n degrees. this is, of course, totally up to you as to what fits best with your lighting style, but i found it much faster to put X/Y/Z into 3PC spreadsheets than to try and get rotation angles correct, render, repeat...

[quote=FirmamentFX]onClick, a UI will pop up asking for hanging position.yeah, to get all the wiring to be brain-dead simple, you almost have to. just don't forget that you can now fly (cascade, even) your hisides in at will, and they'll maintain their focus for you.

[quote=FirmamentFX]Perhaps it would be easier to create a simple(ish) UI inside the 3D app (or using the .NET connection in the latest Max) which emulates as closely as possible all the relevant 3PC functions.i did eventually conclude the same, though it was due to (expected) limitations in 3PC, and not the "intercommunication" process. WPF is my new best friend. exactly which 3PC functions are you thinking would be easier to rewrite?

Thanks again Quinn.

Regarding the rewrite - at the *very* least I would want to implement is palletes, groups, and the functions (DMX channel controls) of each of the lights (although the behaviour of each of the lights is probably best kept in a "personality" script - which could also provide the geometry data to render the lights - to enable the core plugin to just concentate on managing the cue data rather than animating the lights).

In the long term, it would be great to have a system where scenes/shots could be lit using 3PC or a custom plugin based on the functions of 3PC, which would allow 3D scenes to be lit as if they were "real-life" scenes.

That is a long term goal though...

Martin

[quote=FirmamentFX]That is a long term goal though...
i've rescinded, expecting that the next generation consoles will provide the ACN suite; i hope to "dump" an entire show up front as Synchronization Groups with keyframes serving as Atomic Triggers.