FxComposer 2 Beta has just been released...its got a whole whack of new features including CgFx and OpenGL, COLLADA support, among some other awesome things, read here: http://developer.nvidia.com/object/fx_c ... _home.html
Now, one of the features is full python scripting support...so I propose a FxComposer2 -> .material exporter.
This would open so many doors and help us programmer types make some nice looking shaders
kcbanner wrote:
Now, one of the features is full python scripting support...so I propose a FxComposer2 -> .material exporter.
...
Is anyone interested in doing this?
Go for it, let us know when you are done and it's available.
BTW, I don't recall seeing a Linux version of FX Composer on nVidia's site -- did I just miss it somewhere? (Those not on IRC last night won't understand this last bit).
/me is going to have to look into virtualization soon
You could actually look at the source for the RenderMonkey exporter -- it's done in Python. I plan on redoing that one in C++ because, well, trying to use it when you don't want the pain of assembling a working Python install (and the right version, of course) is more than its worth for that. However, it could be useful if you wanted to work up a FXC exporter, since at least the backend code would already be done more or less...
this would be awesome as most artist friendly tools export to .FX and so far I've had very good results loading them into FX composer 2 and having them compile correctly.
Something like RMogre for fxcomposer would make things MUCH easier.
Rendermonkey doesn't import shaders at all making it almost useless if you use other tools to make your shaders. You can't even paste the .fx source straight into render monkey because everything is compartmentalized into seperate sections of the material tree. So you never see all the source at once.
Not sure what ATI were thinking when they made rendermonkey to be honest.
A decent .FX exporter for FX composer 2 would provide an easy path to getting shaders out of shaderFX and Mental mill and straight into ogre
The tool itself seems damn good - a lot nicer than Rendermonkey now. However, the SDK docs are spotty - I can't find any way to even access the guts of an effect through their code currently (at least in Python). The samples all appear to be basic GUI control things.
I'm sure it's doable, just one of those things where they're still in beta and the docs are still pretty shakey.
Update: I played with the Python console a bit after I posted this and got a list of values from the material, but they're unlabeled. It's been a long time since I've used Python, so I'm not sure how to get much more out of it without some more study. I personally would like to get this exporter going myself, I could use it for my own artists.
If anyone needs a hand working this out, please let me know -- I'm at NVIDIA and have written most of the sample shaders and have been delving deeper into the Python scripting now that the stable release version is here. A nice advantage is that I can ring up the programmers and pester them when I don't understand something....
Geryon wrote:...got a list of values from the material, but they're unlabeled. It's been a long time since I've used Python, so I'm not sure how to get much more out of it without some more study. I personally would like to get this exporter going myself, I could use it for my own artists.
Check out the latest beta, I've started including extra query/probe scripts for Effects, Materials, Material Parameters, Images, etc.... look for scripts labelled simply "Effects.py" etc
If anyone needs a hand working this out, please let me know -- I'm at NVIDIA and have written most of the sample shaders and have been delving deeper into the Python scripting now that the stable release version is here. A nice advantage is that I can ring up the programmers and pester them when I don't understand something....
Great to see that someone like yourself at Nvidia understands Ogres importance...
Geryon wrote:...got a list of values from the material, but they're unlabeled. It's been a long time since I've used Python, so I'm not sure how to get much more out of it without some more study. I personally would like to get this exporter going myself, I could use it for my own artists.
Check out the latest beta, I've started including extra query/probe scripts for Effects, Materials, Material Parameters, Images, etc.... look for scripts labelled simply "Effects.py" etc
They're in ....\FX Composer 2\MEDIA\scripts\
Beauty! I will do that. Is that beta 4 they're in?
I'm planning on putting my new junior hire here on an exporter. We'll see whether the higher ups let me release it or not.
EDIT: They don't appear to be in the beta I have (beta 4). I take it there's probably a more recent beta for registered developers. Speaking of which, that process seems ridiculously hard, since the form is broken and asks for a lot of information I really don't have the clearance to give out.
Last edited by Backov on Mon Jul 16, 2007 10:30 pm, edited 1 time in total.
I hope someone picks up on the offer of help. FX composer is a marked improvement over rendermonkey and the first FX composer. Seems like exactly what we need to make shaders more accessible.
Every time I make some progress converting FX files, I end up needing to tweak something and find another layer of complexity that makes the methodic conversion I was trying for that much more complicated.
What's the latest on support of the latest FX features (in the FX --> .material converter.. if there is one)?
Being able to trivially load in Ogre any FX file would be REALLY great.
I'll grab the latest code from CVS and see what the comments in the code reveal. (If I can find anything at all)... if anyone can offer any insight please do!
Like I said in the other thread, I've taken over the RM exporter with the intent of making a C++ version that does not rely (artifically, that I can tell, in terms of the current one) on Python. I haven't done it yet for the reasons I stated over there -- RM is simply inferior to FXComposer.
However, one of the devs on FXComposer at nVidia has offered assistance in these forums on making an FXC-->Ogre exporter (oddly enough, in Python, but since Python is supported directly in FXC it's not as big an issue as forcing the extra dependency is in the current RM exporter). No one as yet has taken him up on that, and since our project is not yet at the stage where we need that functionality, I've not looked further into it personally.
You may just be stuck with copy/pasting the shader code from the FXC or RM .fx export, and sticking it into an Ogre material. Hardly the ideal solution, but it works, and for now, since this is an open-source effort, you can either wait for someone else to get around to it, or create such an exporter yourself.
I started fiddling with this again -- all I need to do is work at night on the weekend
Getting simple output of material values from FX Composer to an Ogre material is not particularly difficult using the existing FX Composer Materials and Effects modules. In fact the code is pretty short! It's a typical stack of loops:
for each material
for each profile in the effect for that material:
for each technique in the profile:
for each pass in the technique:
for each shader in the pass:
for each shader parameter...
What's TOUGH is if the code inside a shader function depends on globally-scoped parameters -- that is, values that are not passed directly to the vertex or fragment shaders, but rather are inherited from the surrounding .*fx scope. Ogre doesn't seem to have such a surrounding scope, so digging down within the HLSL or CgFX structures is a bit harder.
One solution might be to simply ignore those global parameters, maybe printing a little cautionary message if the code thinks they may be present but otherwise just depend on the formal parameters of the shader functions. It makes for a much cleaner setup all 'round -- it might not hit 100% of the corner cases, but if something simple can tackle 90% of all shaders.....
bjorke wrote:I started fiddling with this again -- all I need to do is work at night on the weekend
Getting simple output of material values from FX Composer to an Ogre material is not particularly difficult using the existing FX Composer Materials and Effects modules. In fact the code is pretty short! It's a typical stack of loops:
for each material
for each profile in the effect for that material:
for each technique in the profile:
for each pass in the technique:
for each shader in the pass:
for each shader parameter...
What's TOUGH is if the code inside a shader function depends on globally-scoped parameters -- that is, values that are not passed directly to the vertex or fragment shaders, but rather are inherited from the surrounding .*fx scope. Ogre doesn't seem to have such a surrounding scope, so digging down within the HLSL or CgFX structures is a bit harder.
One solution might be to simply ignore those global parameters, maybe printing a little cautionary message if the code thinks they may be present but otherwise just depend on the formal parameters of the shader functions. It makes for a much cleaner setup all 'round -- it might not hit 100% of the corner cases, but if something simple can tackle 90% of all shaders.....
Actually, Ogre does have these global params; they mostly are the auto_params in the material/shader definitions. Standard Cg semantics such as WorldViewProjection can be mapped directly to Ogre auto-params.
The problem is that Ogre does not have the notion of "material instancing" that COLLADA has, so parameters assigned to fixed-function materials have no real meaning in Ogre unless you want to make a new material for each.
I am working on an Ogre <--> COLLADA importer/exporter right now and this is something I actually am working on at the moment (general support for material params via the instance_controller and instance_geometry elements in the COLLADA scene graph).
But ya what Kevin says is correct -- there is no real direct mapping for a lot of what is in COLLADA to how Ogre deals with stuff.
Cool -- I *am* actually working on this some more, wedged-in among about 8 other things (and I even mentioned Ogre in the press this morning ). I know it seems slow -- to a degree it is, since I'm approaching it in part as an element of making our tools and shader library more-accesable to a variety of game engines and developers, and have been working on a massive editing task that re-writes most of our library to NOT use those problematic global variables, which can be a pain for any developer (not just Ogre developers) who want to be able to cut-n-paste shaders into their own games.
That said, I'm really hoping to have a version up and running before I head off in two weeks for a month's worth of Chinese food
(Those not on IRC last night won't understand this last bit).
