PDA

View Full Version : My first plugins... ;-)


ThomasHelzle
09-26-2003, 06:16 PM
Hi,

I'm currently coding my first series of plugins. It's a collection of small and simple shader modifiers like bias, gamma, invert, scale etc. for easy image modification inside Messiah:Studio.
After solving a crash-problem when only defining _MESSIAH_PLUGIN_SHADERS instead of _MESSIAH_PLUGIN_ALL it works great so far, but I would like to put some text in the shader blocks with information on use, possible values etc.
But I haven't found a static text-control in the gui header yet. Can someone point me in the right direction?
How do I put text in the interface?

Another question:
Will the color space change when HDRI is finally implemented in the renderer? I'm thinking about this because I'm trying to implement an as flexible approach as possible. Does it make sense to invert colors with _out_color.r = 1- _in_color.r
Values above 1 will become "Superblack" then...?

Thanks for any help!

FB_Turbine
09-26-2003, 09:04 PM
At the moment the only thing I can think of is to either try fxCC_Area or use message post connected to a button event to pop up a dialog with descriptive information.

lmilton
09-26-2003, 09:08 PM
Originally posted by Thomas_Helzle
Hi,

I'm currently coding my first series of plugins. It's a collection of small and simple shader modifiers like bias, gamma, invert, scale etc. for easy image modification inside Messiah:Studio.
After solving a crash-problem when only defining _MESSIAH_PLUGIN_SHADERS instead of _MESSIAH_PLUGIN_ALL it works great so far, but I would like to put some text in the shader blocks with information on use, possible values etc.
But I haven't found a static text-control in the gui header yet. Can someone point me in the right direction?
How do I put text in the interface?


I'm not sure why the _SHADERS define didn't work. There must be some critical compenent missing.

As far as a text control, we do have a control, but haven't released it yet. We need to perform more testing before it's ready for general use. We'll let you know when it's available. In the meantime, it's a good idea to follow Simeon's lead: create a text file for docs.

Hmmm... come to think of it, you could create a button that would launch your docs with NotePad or WordPad. It seems that would be better than drawing the docs on the interface.


Another question:
Will the color space change when HDRI is finally implemented in the renderer? I'm thinking about this because I'm trying to implement an as flexible approach as possible. Does it make sense to invert colors with _out_color.r = 1- _in_color.r
Values above 1 will become "Superblack" then...?

Thanks for any help!

messiah already stores/computes in floating point space. The values only get clamped when writing out to a standard rgb format. However, if you feel that you'd still like to perform some sort of modifications to the values, it's better that you add some sort of switch on your interface. Also, I believe that Ron will be creating a "math shader" that will allow form more mathematical control over the values.

-lyle

lmilton
09-26-2003, 09:11 PM
Originally posted by FB_Turbine
At the moment the only thing I can think of is to either try fxCC_Area or use message post connected to a button event to pop up a dialog with descriptive information.

_Area won't do it. However, your other suggestion sounds cool.

This is Max, right? I can only tell from the web address.

We added a function that you can use to update motion after editing. It should fix the problems you were having.

-lyle

lmilton
09-26-2003, 09:17 PM
BTW, Thomas, are you going to release your plugins & code to the general public, or are they proprietary?

-lyle

ThomasHelzle
09-26-2003, 09:28 PM
Thanks for the suggestions! What I'm after with the text isn't a "helpfile" but one sentence of info to give a quick hint/reminder about what the tool is doing - I personally like that very much. Think how hard the expressions would be to use without those little explanations.

So maybe I will just wait a little for the text control.

I don't know if this is possible already, but it would be nice (and neccessary soon :)) to have submenues in the shaderlist (and other lists too). I plan to do ~20 little helper tools and they would be best organized in a submenue. The Submenue should be createable either by the developer or reflect the structure of the plugin menue, so that a subfolder with plugins on the disk would be seen as a Submenue with plugins in messiah. The second approach would be very flexible for the user.

The other approach in my case would be to make one shader and a function list in the interface, but I don't know yet how to change the interface of a shader/block...? Is it possible?

FB_Turbine
09-26-2003, 09:34 PM
Originally posted by lmilton
_Area won't do it. However, your other suggestion sounds cool.

This is Max, right? I can only tell from the web address.

We added a function that you can use to update motion after editing. It should fix the problems you were having.

-lyle

Hi Lyle,
Yep this is Max. Great news on the motion function :buttrock:

edit:
Thomas_Helzle, maybe obvious but \n for new lines works in the message post function if you want to go into a little more detail.

ThomasHelzle
09-26-2003, 09:37 PM
- Hm - good question... haven't thought about that...
They are quite basic, so it may be a better idea to make them free - maybe open source, so people are able to look at more examples...
If I make them open source, I think it would be great if you could look into the code (after the release of course) if I've done everything correctly ;-)

BTW. I'm currently using the MS VC++ 6 Standard Edition (without code optimization). Do you think the missing optimization will cause much slowdown with shaders?

What are you guys using? Intel Compiler? AMD Code Optimizer? Or just plain vanilla VC++?

Any special tips on optimizing shaders but the obvious (precompute static values etc.)?

Thanks!

ThomasHelzle
09-26-2003, 09:44 PM
Thomas_Helzle, maybe obvious but \n for new lines works in the message post function if you want to go into a little more detail.

Hehehe - is that tip because I'm always writing such long mails? ;)
Just kidding - Great suggestion, I will try that if the text-field is taking too long ...

lmilton
09-26-2003, 09:57 PM
Originally posted by Thomas_Helzle
- Hm - good question... haven't thought about that...
They are quite basic, so it may be a better idea to make them free - maybe open source, so people are able to look at more examples...
If I make them open source, I think it would be great if you could look into the code (after the release of course) if I've done everything correctly ;-)


I'm going to assume that if it works, it's fine;) I do think it would be good for the messiah community to see the plugins & code. This will help everyone understand just how easy it is to create messiah plugins. Just try to include comments as necessary.


BTW. I'm currently using the MS VC++ 6 Standard Edition (without code optimization). Do you think the missing optimization will cause much slowdown with shaders?


We're using 6 professional. With shaders & writing renderers in general, you'd be surprised at what could actually cause slowdowns. But with very simple utility shaders, you should be fine.


What are you guys using? Intel Compiler? AMD Code Optimizer? Or just plain vanilla VC++?


Plain VC, right now. We do have the Intel Compiler, though. I haven't run many tests, myself.


Any special tips on optimizing shaders but the obvious (precompute static values etc.)?

Thanks!

It all depends on the shader, really. I will say, though, that we tend to limit the number of function calls within evaluate (whenever possible). Also, be careful of having any uncessary variables; we've seen some odd slowdowns on complex scenes when there is exessive variables.

There's much more, but that's all I can think of, off the top.

-lyle

ThomasHelzle
09-27-2003, 09:50 AM
Some other questions:

How can I determine if a shader input is connected to something or not? Is there a special Flag? If not, could this be implemented in a later patch?
I would like to handle things different, depending on that.

Will the image-processing surface of the camera be included with the next patch?

Are the precautions for threadsafe-rendering the same as in other software? Like always retrieving/using local copies of variables and the shaderdata etc.

Is there a sample for changing the interface depending on user input in the SDK? I think of things like having 1 input field for a gamma tool, then switch to something else with 4 inputs and a dropdown.
I'm trying to decide if it's better/easier to make one shader that can be switched between different modes or a lot of shaders with limited functionality. I like the way Sabre handles this (lots of well organized simple tools), but since there are no submenues in messiahs shaderlist, it will be cluttered easily...

Thanks a lot!

:bowdown:

Panikos
09-28-2003, 11:25 PM
Danke Thomas.

Prost !:beer:

ThomasHelzle
09-29-2003, 10:38 AM
"Tommys Little Helpers" or TLH for short ;-)

Now available for download from my website:
A suite of little helpertools for the shader flow of Messiah:Studio Rev9b.
Please report any errors, problems, praise and suggestions so I can continue to make the tools more useful for everyone.

Have fun!

Edit: Update to version 1.1 is available now with 3 new tools: HSVtoRGB, RGBtoHSV and Channels.
There are now 12 tools total.

http://www.screen-dream.de/plugins.htm

Panikos: You're welcome! :beer: :)

http://www.screen-dream.de/images/tommys_little_helpers.gif

lmilton
09-29-2003, 06:34 PM
Originally posted by Thomas_Helzle
Some other questions:

How can I determine if a shader input is connected to something or not? Is there a special Flag? If not, could this be implemented in a later patch?
I would like to handle things different, depending on that.


Planned.


Will the image-processing surface of the camera be included with the next patch?


No, this area isn't activated yet. For the next [1.5] patch, we wanted to focus almost exclusively on render bugs. We have new features that we'll be adding, and you'll get them in a later patch... this includes the Camera:Image Filter surface.


Are the precautions for threadsafe-rendering the same as in other software? Like always retrieving/using local copies of variables and the shaderdata etc.


Same as other software. However, you can get the thread ID (shader_globals->tid) to help with managing your thread data.


Is there a sample for changing the interface depending on user input in the SDK? I think of things like having 1 input field for a gamma tool, then switch to something else with 4 inputs and a dropdown.
I'm trying to decide if it's better/easier to make one shader that can be switched between different modes or a lot of shaders with limited functionality. I like the way Sabre handles this (lots of well organized simple tools), but since there are no submenues in messiahs shaderlist, it will be cluttered easily...

Thanks a lot!

:bowdown:

After looking at the image you've posted, it appears that you only need one shader. You could create a popup list control to allow the user to change the behavior of the shader.

As far as changing the inputs/outputs on the same shader... *never* attempt to do this. messiah keeps track of the inputs/outputs per shader; attempting to change the number of inputs/outputs for the same shader could be fatal.

However, in your case, you don't need this. Your output is the same, so there's no problem there. There's only a few deviations on the inputs; either supply an input that would function as gamma, offset, bias, etc., or just supply all of the relevant inputs on that same shader.

Let me know if this is clear...

-lyle

ps: we have plans for shader management, there just isn't much that we can do in this version.

ThomasHelzle
09-29-2003, 06:54 PM
Lyle, thanks for the info.
So until the "is something hooked into the input"-Flag is available, my only option is to compare the current input with the default input, but I'm not sure if this would be slower than just computing my quite basic formulas ;-)

I will have to think about the "one shader option". Maybe I will make 3 or 4 classes for the 1, 2, 3 input shaders so the interface doesn't get cluttered.... hmmm ;-)

lmilton
09-29-2003, 07:02 PM
Originally posted by Thomas_Helzle
Lyle, thanks for the info.
So until the "is something hooked into the input"-Flag is available, my only option is to compare the current input with the default input, but I'm not sure if this would be slower than just computing my quite basic formulas ;-)

I will have to think about the "one shader option". Maybe I will make 3 or 4 classes for the 1, 2, 3 input shaders so the interface doesn't get cluttered.... hmmm ;-)

I'm not sure why you would need to determine if there is something connected to the input... what do you mean by "compare the current input with the default input"?

-lyle

ThomasHelzle
09-29-2003, 07:23 PM
Since my tools only work on input, it seems quite useless to compute anything if there is no input and I could skip the whole evaluation in that case.
Are there better ways of optimizing/doing this?

Are there RGB to HSV and HSV to RGB functions in the SDK?

Are the noise functions accessible for plugins?

Thanks a lot!
:wavey:

lmilton
09-29-2003, 07:34 PM
Originally posted by Thomas_Helzle
Since my tools only work on input, it seems quite useless to compute anything if there is no input and I could skip the whole evaluation in that case.
Are there better ways of optimizing/doing this?


I wouldn't worry about that. If the user adds your plugin, he/she should know that it only operates on input (i.e he should know what's it's designed to do). So, if someone adds it, and doesn't feed it any input, it's really not *your* problem. That may sound a bit callous, but it's important that the user makes at least a *little* effort to understand your plugs... or you run the risk of slowing your shaders by running unecessary tests.


Are there RGB to HSV and HSV to RGB functions in the SDK?


No, but I'll add 'em to the list.


Are the noise functions accessible for plugins?


I believe that Ron was planning something, but I suppose I could just publish what MultiNoise is using. I'll do a little investigating.


Thanks a lot!
:wavey:

No prob:)

Panikos
09-29-2003, 11:11 PM
Lyle

Any future plans for various Cameras Projection simulation ?
i.e Orthographic, FishEye etc ?

Its very fashionable lately for the majority of 3d-apps to abandon the pinhole camera
:shrug:

CGTalk Moderation
01-15-2006, 12:00 PM
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.