SDK Feature?


#1

Does anyone know if the SDK exposes access to a wav file’s data? If not could I open and access the data of a wav file in my plug-in? I would most likely need a way of persisting some of the information is well. Does data have to be native to messiah to get persisted?

Thanks!


#2

Since nobody from pmG answered your questions (I don’t get any answers from them for weeks now too :frowning: ) I will try to at least give you the little bit I know:

I haven’t seen any wav-access in the SDK.
I would think it is best to load the file yourself from your plugin (with the usual windows file requesters code) and then do with it whatever you want/need.
If you can be more specific about what you want to do, I can maybe give more hints.

Your plugin can have it’s data saved: see the docs -> Concepts -> Common Tasks -> Data Attachment.

You will soon find that some parts of the SDK are fantastic (displacement, shaders) while other important stuff is very primitive or even non existant (geometry creation, file IO, particle access…) . There isn’t even something as simple as a static text control for your GUI or a user definable interface area where you can draw your own stuff…

I get more and more frustrated by the functionallity and the support for the SDK, but I will be happy to share the little I know :shrug:

Cheers,


#3

Thanks for the response. Maybe the guys at pmG are busy with something at the moment? I kind of got the impression that they were pretty accessible and even sometimes are willing to add functionality in certain cases (could be wrong). I also posted this in the Yahoo group but didn’t get a response there as of yet.

That kind of sucks about the text control and especially not being able to draw something for display purposes but maybe there’s some ways around it…or maybe they would be willing to expose such a thing if enough people requested it. But you did answer my questions well enough to help me out. Thanks!

BTW, still playing with AoN. No worthwhile examples yet, but it sure is fun!


#4

BTW, still playing with AoN. No worthwhile examples yet, but it sure is fun!

Cool :thumbsup: :bounce:


#5

There’s quite a bit of depth to your shaders. One could spend eternity tweaking them. In your docs you mention how all the channels of a shader are outputting values. Do they all output the same type, or do some output a color value, others a float, etc?

Back on the subject of SDK functionality…you mentioned there is no geometry creation in messiah, but what would prevent someone from writing a plug-in modeler? If it provided all the tools for creating and modifying geometry couldn’t it just rely on messiah for persisting the data?


#6

There’s quite a bit of depth to your shaders. One could spend eternity tweaking them. In your docs you mention how all the channels of a shader are outputting values. Do they all output the same type, or do some output a color value, others a float, etc?
Hahahaha - Yes!- Ages of fun :wink:

My intent with that explanation was, to show that basically everything is just values that you can use with everything else in a node based system, since a lot of people think that a “color” is somehow mystically different from a “bump” value, although it is all just the same numbers in the end, just three instead of one.
All AoN:studio-nodes have at least 4 outputs (besides the default Opacity that messiah always creates). The “Color” outputs output three float-values (normally between 0.0 and 1.0) for R, G and B while all other outputs (Alpha, Value, Bump) deliver single float-values. (internally I use doubles for higher precision).
messiah converts that stuff on the fly, so you don’t have to worry much most of the time. You can plug a value into a color and messiah will use it as a greyscale color. The other way around, messiah will use the average of the three color values.
But if you - for instance - plug a color output (red dot) into a vector input (yellow dot -> size, offset, rotation), each color component affects an axis (red->X, green->Y, blue->Z) so you can control them independently. And don’t fear to enter a color like RGB(10000, -2000, 8) if you need that as an offset/rotation/whatever value for another shader.

Internally these are structs that you access with .x, .y, .z or .r, .g, .b. and that messiah translates 1:1 into each other.

Back on the subject of SDK functionality…you mentioned there is no geometry creation in messiah, but what would prevent someone from writing a plug-in modeler? If it provided all the tools for creating and modifying geometry couldn’t it just rely on messiah for persisting the data?

That is a good example about how unbelievable limited the SDK is in that area: You can’t create geometry (there is no way to tell messiah to create a vertex, an edge, a polygon, so your modeler would be unable to do that). You can’t create any interactive tools (manipulation handles etc.). You can’t even select points or polys of existing geometry in the interface.
That is also the reason why you can’t write an object importer yourself. You can read the data no problem but there is no way to make a visible object from that.

Otherwise we would see a lot more plugins I think.

Best regards,


#7

No, the wav file data is not exposed to the API. You can, of course, load your own data.

What exactly are you trying to do?

-lyle


#8

Ok, I actually have two things I would like to do…

The first, relating to the wav file question, is a sort of messiah mo-graph plug-in. Basically use the various types of information produced by sound to drive animation channels, shader channels, etc.

The second is a modelling plug-in. Ideally I suppose it would show up as a new tab making use of messiah’s viewport and camera while the plug-in handles the geometry creation and transformation code.


#9

You wouldn’t want to rely on messiah’s Play->Wave Audio module for that. It would be a better idea to actually bake motion from an audio file, via your own custom Edit module. Alternatively, you could create a Function that references an audio file and converts to motion data. It could be of the form: YourAdioFunc(obj, “audio\dialogue.wav”, NOW).

Of course, both option require that you load the audio files yourself. This may change in later versions, though.

You can’t currently create geometry in messiah; it’s not a modeling app. However, we are exploring the idea of publishing mesh creation/editing to the API. There seems to be quite a lot of interest in this functionality. We’ll let you know when we have something to report.

-lyle


#10

Could you go into a bit more detail about what you mean by “bake motion from an audio file”?
I am playing with the SDK and I will see what I can come up with.

As far as exposing some sort of functionality for modeling…well, that would be awesome. I know messiah isn’t a modeller, but it would be cool to have a plug-in out there that was.


#11

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.