Search this blog


18 January, 2012

Prototyping frameworks

Every now and then, I look around for prototyping frameworks for my rendering work. I always end up with very little but maybe I'm too picky or too lazy. Here are some I've found:

I actually use:
  • FXComposer, both 2.5 and 1.8 (Nvidia does not host it anymore, so you have to google it) as they both crash/have problems in different ways. In particular, 2.5 seems to have problems clearing rendering targets (I use a pass with ztest always to clear), 1.8 crashes in some situations. 1.8 is also nicer for a programmer, but 2.5 is fairly usable. I use SAS and NVidia has some documentation (finally!) about it, to script render passes. In theory both also support proper scripting, but the documentation is thin. A few times when I wanted to look inside FXC 2.5 I used something like ILSpy or .net reflector to delve in the undocumented parts (that's to say, almost everything).
  • Wolfram's Mathematica. I wrote a couple of articles on this blog about it, it's great and I love it, I love the language, it's not what you would expect if you're a mathematician but for a programmer is pretty neat (well at least, if you like lisp-ish things, which you should, syntax apart)
  • SlimDX or SharpDX, to tell you the truth I mixed them up a few times, the names are similar. Bottom line, a DX wrapper for C#, I love C#. SharpDevelop if I don't have an updated visual studio which supports the last .net framework.
  • Processing. I wrote an article on the blog about using it with Eclipse for live-coding, it's neat, it's simple, it has a ton of libraries at this point, even to do 3d stuff and shaders but I use it mostly for 2d prototypes.
  • ShaderToy. There are a ton of offline programs that offer similar functionality, even on iPad, wherever, it's very popular. But. Having it online is nifty for some quick tests. Unfortunately crashes often on certain browsers. There are also lots of alternatives (kickJS editor, Shdr, GLSL playground and SelfShadow's playground), some more powerful (WebGl playground which also supports three.js), but ShaderToy is the most popular.
  • 3D Studio Max. It has an horrible support for shaders (at least it used to, and I suspect not much has changed since) and I never loved it (I love Maya even less though), but I used to know it (six years ago or so) and know maxscript, so I ended up prototyping in Max a few things. It can be handy because you can obviously manipulate meshes all the ways you want and define vertex streams and visually paint attributes on meshes. You can't really control the rendering passes though, so doing non-surface shaders or stuff other than the most basic post-effects is hard. Nowadays I don't use it much if at all.
Seem promising:
  • PhyreEngine, if you have access to the Sony stuff... Might be a bit overkill as it's a fully fledged engine, so the learning curve is not so steep per se but there are tons of examples.
  • Erik-Faye Lund published the sources of his "very last engine ever" which is used in a bunch of great demos (as in demoscene) I didn't have the time to look into it much yet, but the name sounds great!
  • Karadzic's BGFX wraps Dx9, 11 and OpenGL. Neat, even if I don't necessarily care much about being cross-platform while prototyping.
  • Hyeroglyph 3, it's the 3d engine that "ships" with the Practical Rendering and Computation with DirectX11 book (which is nice). It still has a bit more things that I'd like to (more of an engine than a framework) but it's nice. 
  • Matt Pettineo also hosts many XNA and DX11 samples here, which could be a good starting point for a beginner.
  • Matt Fisher BaseCode could be handy for some kind of experiments.
  • Cinder looks still a bit young, it has many nice things but it lacks some other which I would consider "basics". I feel the same about openFrameworks and to me Cinder looks nicer. Plus I don't love C++ :)
  • Humus Framework 3. This is great, it's simpler than a full fledged engine, it's easy to read and it has tons of examples and Humus is notorious for his graphic demos, which all come with sourcecode and were made with his framework!
  • Intel's Nulstein. I didn't spend much time looking at this, Intel "makets" it as the most bare-bones, next-gen engine source possible. Which sounds good, but from the little I saw, it's still not simple enough for my purposes (I really would like not needing to learn anything :) otherwise I could just write my own stuff). Also Intel with its Visual Adrenaline initiative seems committed to providing great support, articles, sourcecode and tools for graphics development.
  • VVVV. It's a node-based graphic thingie. Which would seem like the least suitable thing for rendering prototypes, but it supports shaders, and it supports "code" nodes where you can write C#, so it might be worth a try...
  • OpenCL Studio looks great to me but I didn't have the time yet to test it out properly
  • Python. Lots of people love it and there are tons of libraries, environments, wrappers and so on. You can access DirectX11 or OpenGL. The latest someone told me about is python(x,y) for scientific computing. I don't use python. Maybe I should.
What I'd love? I'd love to have a very simple wrapper, just slightly more high-level than the base API to get me some of the most common stuff already coded (i.e. a camera system, parameter manipulation and serialization, mesh management and loading...), and I'd love if this wrapper was embedded in a live-coding language, like Lua with script hot-swapping (or C# with a file change listener which recompiles on the fly modified scripts), and if it supported hot-swapping (or better, live editing via file-watching) of all the assets as well (shaders, textures etc...). I always think I should code such a thing sooner or later but I never find the time to do it :(


KB said...

Wow, someone still using FXComposer... guess there never really was anything else like it.

Have you tried using WebGL as a lightweight framework, say under three.js? No MRT, limited capabilities, but a simple quick turnaround -- edit in one window, render in Chrome...

I started doing that when I realized I could use processing.js in mobile Firefox on my Android tablet while commuting on the train (just a little graphics OCD)

DEADC0DE said...

That's not a bad idea, I should try. I hate GLSL though, but maybe it got better

matt said...

I used to use FXComposer all the time on DX9 (up until very recently in fact) just for the convenience of syntax highlight, easy compilation checks and seeing the assembler output.. not for any of the fancy render targets & scripting handling etc. now on DX11 I haven't found a good alternative so I'm back to visual studio. If there was a dx11 fxcomposer id probably use it though.

btw, GLSL is still horrible, pedantic and the compilation is in the driver so its completely vulnerable to vendor-specific screwups. :)

Anonymous said...

Of course Ati's Rendermonkey (the DLAA source code comes in Rendermonkey format). Needless to say that it is also discontinued.

And Python is great, especially with numpy and scipy (and sometimes the PIL).

David said...

Hey Angelo,

I just grab one of my coworkers demo's from his blog

and modify it. Usually, I can just take one of his examples and hack together whatever I'm doing pretty quick. His code is really lightweight and doesn't have a lot of framework bs.

-= Dave

DEADC0DE said...

anon: I know about Rendermonkey and many people use it effectively. It's not more supported than FXComposer (actually, less), I didn't pick up back in the time when it was cool as it looked way more artist-oriented than FXC 1.8. Nowadays it doesn't make sense to consider it as a tool for the future...

KB said...

btw, if you do try using Chrome+GLSL (this is for prototyping -- not publication -- so worrying about unsupported browsers may not be important!), note that very recent betas of Chrome now support DDS format (at last!)

DEADC0DE said...

KB: publish a tutorial on your blog! :)

KB said...

maybe I will!

Sad to say I actually had a link on G+ about how I was using WebGL for development on RIFT but removed it because it violated corporate policy against talking about internal processes :/

If you hate GLSL (with you there!), you can also use "cgc -oglsl"

Anonymous said...

I thought I'd just drop by and ask the author, what's your opinion on Unity as a prototyping framework?

DEADC0DE said...

I don't know much about it, but from what I've seen and from how a few friends of mine are using it, it seems great for game prototypes, animation and such, but for rendering I really don't want a game engine or even worse, a game editor. I would just like, as I wrote, some basic functions on top of DX to avoid writing the same boilerplate code over and over, coupled with file watchers and hot-reloading for the various types (textures, shaders etc), and maybe some basic interaction stuff like camera, parameter tweaking etc... A glorified FX composer would do great, or if they opensourced it I'm sure we could poke into it to make it good, removing the limitations of SAS... Or even if they documented decently the scripting/plugin stuff...