I’ve been trying to come up with a nice generic way of setting up surface materials/shaders in my renderer. A scripting system seems to be the best approach.
It should include, for multiple passes:-
state setup
vertex attribute stream binding
pixel/vertex shader binding
texture stage setup
additional utility texture objects
sockets for external app defined variables (such as time, weather, animation frame)
etc.
Basically, I want an open ended, future proof(ish) system for setting up shaders/combiners.
Now, I noticed the short pdf ATI produced which describes the system they use in their RenderMonkey shading system, and I’ve played around with RenderMonkey itself, which seems nice enough. I don’t understand how I can make use of RenderMonkey, however, because it doesn’t appear to export any script files etc.
Does anyone have an opinion on the way RenderMonkey does things, or suggestions of papers/documents that I might find useful while addressing this issue?
Thanks.
RenderMonkey does export a script file…well, kind of…it writes XML project file. The XML files have all the shaders’ source and all the render state information you need to render the scene. By extending that XML file with your own tags, you could add additional, application-specific information.
I think RenderMonkey is a cool tool to develop shaders, but what I don’t like about it is, that it is Direct3D-specific.
As for other options, you could look at the effect files that DirectX 8 has. Or, of course, you can just define your own script language.
I believe RenderMonkey may have the sort of functionality you are looking for, it just isn’t easily accessible in the beta that has been released so far. RenderMonkey is a simple shader development tool like you can presently see, but it is also a plugin frame work. Virtually the entire tool is built on the plugin frame work, and it allows for additional plugins for exporting from its internal data format.
The plugin system is not documented in the initial beta, but it is scheduled to be included in the next release. The idea of the plugins is to allow developers to adapt it to their own uses. As far as D3D versus OGL, the previewer itself is a plugin.
I’ll forward this threasd along to one of the team members to see if they can comment further.
I just read more about RenderMonkey cuz before i didnt really know much about it other than a shader preview system. First i must say RenderMonkey ROCKS! The thing that i am pleased about is that it does not require an ATI Radeon to use it, according to the sys requirements. Also i seem to remember something about RenderMonkey being able to parse RenderMan shaders, is that true? If so that’s cool. One thing that i think would also be good is to be able, i guess through a plugin, would be to allow RenderMonkey to parse Cg shaders. Since the source for the Cg compiler is now available that might be able to become a reality.
Thanks for the answers.
I too really like the way it handles, and I’m pretty sure I could make really good use of it if I had the elusive SDK that’s mentioned in various web pages. Unfortunately, I need something pretty quick, as in within the next 2 weeks, so I may have to give it a miss for now.
I’ve got a fair way into writing my own monkey, but it will never parse renderman scripts! That would be a very nice feature to play around with.
Cg support? Well, that should be fairly straightforward to add, I would have thought - you can just use the existing nvidia backend - just pipe the Cg text file editable in rendermonkey through to the nvidia profile and you’re done.
The D3d vs OGL issue is straightforward too - as the constants defined in the state dialogs in rendermonkey seem to have an almost 1-to-1 equivalence with OpenGL. I can understand why ATI have held back producing a opengl preview plugin…it would have to be ATI specific, such is the mess of opengl.
BTW, I can only get the default shader to work on my geforce4 ti, all the rest fail the pixelshader check.
Originally posted by SirKnight:
[b]I just read more about RenderMonkey cuz before i didnt really know much about it other than a shader preview system. First i must say RenderMonkey ROCKS! The thing that i am pleased about is that it does not require an ATI Radeon to use it, according to the sys requirements. Also i seem to remember something about RenderMonkey being able to parse RenderMan shaders, is that true? If so that’s cool. One thing that i think would also be good is to be able, i guess through a plugin, would be to allow RenderMonkey to parse Cg shaders. Since the source for the Cg compiler is now available that might be able to become a reality.
-SirKnight[/b]
rendermonkey can indeed compile RenderMan shaders but this functionality is not exposed in the current beta. i’m not sure when this functionality will be exposed (it’s gated by DirectX 9.0). as for opengl support… you can wait for the SDK to be released and then write opengl plugins but this introduces new problems (ie. as far as i know, there is no ARB extention for fragment shaders). as someone pointed out, the render state and texture state maps very nicely to opengl state so this is another option (just read in the rendermonkey xml workspace and start setting opengl state). i’m glad to see people using the tool
If you could rush out another beta with the sdk included, I for one would be very grateful.
After playing with rendermonkey, I’ve decided to dig out my old radeon 8500 to give it a proper once over - god I hope your drivers have improved since the last time I tried the damn thing, otherwise I’m in for a long night.
You are right there is no ARB fragment shader extension yet. But that will be in OpenGL 1.5 so maybe next year? Using the stardard opengl render states would be a nice option to have in there. It could be made like in that stanford paper (i think it was stanford) where a renderman shader was broken down into as many passes as needed to run in standard opengl. Of course for us NV people, we can always use nvparse w/ PS1.1.
RenderMonkey seems so far to be a big hit and I believe it’s only going to get better. It was a very smart move to design it the way it is, with the plugin system and all. Very nice.
Well, I installed the radeon8500, latest drivers etc.
Rendermonkey is nice, but unfortunately I discovered that ATI’s favourite colour is still BLUE. Click one of the bumpmapping effects, go into the RenderStates, change the fillmode to points - bang, blue screen.
Please don’t tell me its because rendermonkey is in beta - beta or not, no software should be able to cause the driver to blue screen, because a driver should never allow itself to get in such a mess.
I wish ATI would make the nvidia driver writers an offer they can’t refuse.
[This message has been edited by knackered (edited 09-04-2002).]
hehe, nvidia loves blue as well… on about every xp machine its easy to get bluescreens, their xp drivers are really not that well… and well, on win2000 as well… on win98 you normally not know what caused the fault
Originally posted by davepermen: hehe, nvidia loves blue as well… on about every xp machine its easy to get bluescreens, their xp drivers are really not that well… and well, on win2000 as well… on win98 you normally not know what caused the fault
Bah, I’ve programmed 8 hours a day for 2 years on Win2k using nvidia drivers and can still count my bluescreens on one hand .
Are you sure that there isn’t something wrong with your hardware, Dave? Bad memory sticks or heat problem or something?
– Zeno
[This message has been edited by Zeno (edited 09-04-2002).]
I would have to dissagree with you on that Dave. I only remember getting a bluescreen once that was caused by the video drivers. Thats because i had a hardware problem and it was causing all kinds of wierd things to happen in addition to that video crash. Since I corrected this I have not had a BSOD with the nvidia drivers. Oh I have XP Pro BTW. I think also at the time I also had some beta drivers so that didn’t help. So if you get a lot of blue screens on 2k or XP then something is screwy with your hardware or some gimped software or OS config.
-SirKnight
[This message has been edited by SirKnight (edited 09-04-2002).]
knackered,
for the last year, year.5, that I’ve been using W2k, I’ve only experienced a stop screen twice, both times related to a NIC going bad and fowling something up on me (IRQ_LE error). I’ve had my 8500 in my system since May and have never gotten any stop screens (managed to lock my computer up with my GL programs, but those are bugs I’ve been reporting to the ATi guys and gals) But in terms or normal system operations, I couldn’t be happier with the card. Same thing goes for ye’olde GF2MX I had before it, never had any problems whatsoever with it except for goofy problems with my apps.
Staying on topic…
As for RenderMonkey, I like the way it looks and feels so far, but I’m still finding my way around it. I’ll reserve judgement once it’s at version 1.0, but so far my thumb is having an opposite gravity effect about it
knackered, not sure if this is what you’re after, but there is a great .pdf on ATIs site called “designing a shader library for next-gen hardware” or something like that, that talks about implementing just the kind of scripting system u mentioned. also the .pdf on “designing Sushi - how hardware guys make 3d graphics engine” (again, approx title) is also very good.
i was so inspired i have spent the last week or two playing with Flex and Bison trying to get something similar up and running… very cool. lets me link up various shader variables to attributes of any node in the scenegraph etc.
>>Basically, I want an open ended, future proof(ish) system for setting up shaders/combiners.<<
i havent seeen rendermonkey so i cant comment.
ive written my own shader language before they became the latest in thing now everyones doing it the b*stards
anyways its similar to quake3 but more advanced.
basically each shader is a txt file which does the same effect BUT with various tradeoffs
eg
shader 1
{
the shader with all the bells + wistles (will be chossen with good hardware)
}
…
shader 4
{
a plain decal texture
}
each shader consists of various skins (a bit like passes)
the advantage of this is very easy to expand (with new cards) + tailor make to specific hardware. also for any shadrer language it must be written as a text file (u will usually want to tweak things in game).
ive written an app that makes these text file (what rendermonkey does i gather but mines less advanced).
on the subjects of crashes yes i to find when win2k does the BSOD 90% of the time the fault lies with the nvidia drivers (maybe theyre not at fault but thats the text i usually seen on my screen ie nv34573845 was a bad boy)
OT: I’m willing to entertain the idea that my radeon is in some way physically damaged - that would be the only legitimate explaination (other than bad drivers) for it consistantly giving me blue screens in all the PC’s I’ve tried it in, with every driver release since god-knows-when. Unfortunately, to confirm this I’d have to buy another radeon, but from what I’ve read on the web about other peoples experiences with ati drivers, I don’t think there’s enough of an argument to warrent spending more money on ati hardware. BTW, I’ve never had any blue screens with any nvidia cards on any win2k PC with any of their driver releases - this is a very good record.
On-topic: @vshader : I’ve read that document, yes - its very vague.
I haven’t blue screened once with my new Athlon XP using NVIDIA drivers. With my old pc (mostly the same hardware), which was ****e, I used to blue-screen about once a day. That is, until I removed my even older TV card - which fixed the problem totally
The thing that i am pleased about is that it does not require an ATI Radeon to use it, according to the sys requirements. Also i seem to remember something about RenderMonkey being able to parse RenderMan shaders, is that true? If so that’s cool. One thing that i think would also be good is to be able, i guess through a plugin, would be to allow RenderMonkey to parse Cg shaders. Since the source for the Cg compiler is now available that might be able to become a reality. 
Using the stardard opengl render states would be a nice option to have in there. It could be made like in that stanford paper (i think it was stanford) where a renderman shader was broken down into as many passes as needed to run in standard opengl. Of course for us NV people, we can always use nvparse w/ PS1.1.