PDA

View Full Version : RapidShading 0.4 - Graph Shader Editor



sam7
08-28-2007, 12:05 AM
Hi!
I just finished my degree and developed a tool during my bachelor thesis that evaluated the use of procedural texturing on the GPU. I called it RapidShading. It's a graph-editor to graphically develop GLSL Shaders.
My focus hereby was on procedural textures on GPU.
I'd like to make my tool available to a bigger audience, and make it more of a community project. The application has a few interfaces, that make it easily expanpable via plugIns. So I'm looking for developers to help as well. I'm just working on a good documentation of the interfaces.

The whole application is based on Java and OpenGL (jogl). So when you download the application make sure you have the jogl libraries for your system.

With the download comes a marble texture as seen in the screenshot below, that is entirely rendered on the GPU without texture mapping.

I'd be very happy to receive some feedback. But keep in mind that this project is still in an early stage of development. There are a few bugs that need to be fixed and a few features that need to be completed.

My questions:
Do you think this approach of ShaderDevelopment has a future?
Does the UI structure make sense to you?
What are you missing?
What other ideas do you generate according to this tool?

http://www.procedural-texturing.com/

Thanks!!!

Screenshot:
http://www.procedural-texturing.com/files/screenshots/image2.jpg

predaeus
08-28-2007, 04:23 AM
First of all it is a great and very promissing tool.

But I have a few points where things could be improved:

0. :-)
Pack the application so that it unzips a directory. Like it is now it behaves like a tarbomb and just unzips it's files into the current directory.


1.
It is very unpractical to have to switch between tabs or right-click-option the "Node In & Output vars" and "Node Properties" tabs. Both tabs should be visible all the time. Just make them so one can minimize them like the Shader code output window (which is not important in the design process).

2.
I am coming from the Linux world so:
Deleting nodes should be possible with the DEL key.
Switching tabs (if they remain) should be possible with the ALT-1, ALT-2 ... ALT-n keys (this is how it is done in many Linux tools and also the Firefox web browser).

3.
"Show Variable Types & Names" should be enabled by default, as it will help beginners like me a lot to see where each input and output is.

4.
If several connections are made to a single connector it is sometimes impossible to move the end of one connector individually. Both connectors ends will stick together. Also it seems to be impossible to delete connections (right-clicking or anything did not show an option).

5.
A warning or error message was displayed on the preview window and afterwards the preview was not refreshed, leaving a white box inside it. Maybe the message should be displayed in the graph window.

6.
Copying nodes might be practical in the future.

2 bugs I discovered:

1.
I don't remember what exactly I did, but I think I created a "mix" and a diffuse in the brick demo and messed around with linking diffuse to that mix and also the output of the existing mix to that mix. I changed it around between various inputs and output. Then I grabbed the 2 connectors that where linked onto the same mix input and dragged them to the output of the existing "To vec4" and then the application froze and the console showed an exception that seemed to be stuck in a loop:

...
at sperling.RapidShading.ShaderNode.resolveOutputData Type(ShaderNode.java:122)
at sperling.RapidShading.ShaderProgramInVariable.reso lveDataType(ShaderProgramInVariable.java:149)
at sperling.RapidShading.ShaderPrograms.GLSL.DataType Converter.resolveOutputDataType(DataTypeConverterF actory.java:242)
at sperling.RapidShading.ShaderProgramOutVariable.res olveDataType(ShaderProgramOutVariable.java:150)
at sperling.RapidShading.ShaderNode.resolveOutputData Type(ShaderNode.java:122)
at sperling.RapidShading.ShaderProgramInVariable.reso lveDataType(ShaderProgramInVariable.java:149)
at sperling.RapidShading.ShaderPrograms.GLSL.DataType Converter.resolveOutputDataType(DataTypeConverterF actory.java:242)
at sperling.RapidShading.ShaderProgramOutVariable.res olveDataType(ShaderProgramOutVariable.java:150)
...I can't seem to reproduce it since I do not remember exactly how I did it and the application seem to prohibit dual connectors on the mix inputs now.

2.
When creating new nodes, it always created 3 instead of one.

Anyway great tool that I might use in the near future (my engine has no dedicated renderer yet).

EDIT: oh yea I tested on Linux with an AMD64.

sam7
08-28-2007, 06:17 PM
Thanks a lot for your detailed feedback!
I'll see what I can do. There are some good point, that are not even too hard to fix.

So thanks for that again. :)


Waiting for more... feedback ;)

zed
08-29-2007, 01:26 AM
no go with me

Exception in thread "main" java.lang.UnsupportedClassVersionError: sperling/RapidShading/Editor (Unsupported major.minor version 50.0)
at java.lang.ClassLoader.defineClass0(Native Method)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknow n Source)
at java.net.URLClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.access$100(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClassInternal(Unknown Source)

ZbuffeR
08-29-2007, 08:56 AM
zed, you need to use java 1.6

zed
08-29-2007, 01:45 PM
yeah thanks i see that in the http://www.procedural-texturing.com/ page
sam7 you need to stick this info in the readme which is what most ppl read if they have problems (+ sometimes even before they run the app ;) )

ZbuffeR
08-29-2007, 01:55 PM
Interesting.
Why the connectable yellow ticks don't show a label ?
At least an initial would be great. Waiting for the tooltip to appear is annoying.

sam7
08-30-2007, 01:23 AM
@ZbuffeR

Just use the Ctrl + V shortcut to activate the
"Show Variable Types & Names" Option.

ZbuffeR
08-30-2007, 03:51 AM
Such "beginner options" are great when activated by default. Experts know how to deactivate them :)

zed
08-30-2007, 02:15 PM
yeah first time ild load up with a simple project as well, instead of nothing (next time around loadup last project/default project/empty project etc)

i found the interface a nit laggy (perhaps thats standard with the java/ogl combination donno ive no experience with it)

also the lines between the boxes in the graph were practically invisable (due to my desktop colors). perhaps have your own color scheme

knackered
09-04-2007, 02:20 AM
what's the point in this? what problem is it solving?
no offence intended.
To expand a little on what could on the face of it seem like trolling...
My shader system is tightly coupled with my rendering code, in order that I can quickly determine the shader required for a pass and have the uniform locations and attributes ready for upload. I have a class inside my renderer that tracks the current render states and quickly selects a pre-compiled shader based on this. The shaders themselves are small, inter-dependent modules that I link together with an automatically generated main() function. These shader modules are hand-crafted in order to be as efficient as possible, sharing many calculations between them. The actual shaders themselves are not very complicated to write, so this app you've written seems like gross overkill to me. I can imagine someone using it to prototype some weird effect, but in practice I can't see myself finding a use for it. Maybe in a classroom teaching kids the basics?

sam7
09-07-2007, 01:00 AM
@knackered

Fair enough. I see your point. The thing is, that this tool is probably really for a different use, than yours.

And maybe at the moment it's not even very efficient, but as we look further to what shaderdevelopment is going to be like in 5 years. When shaders can become much more complex, I'm sure you'll see a lot of tools like that, just of course much more complex and userfriendly ;)

And I agree as well, that in order to make this tool usefull it would have to be integrated in a certain gameengine, or game development environment.

E.g. we're just trying to integrate it into the Netbeans OpenGL Pack.

Cheers