PDA

View Full Version : RenderMonkey inspired GLSL editor for linux?



Linsnos
07-21-2011, 01:50 AM
Hi!

I'm working on a (very basic) OpenGL graphics engine using the programmable pipeline.
You can get some more info about it on my blog
deorbit (http://deorbit.wordpress.com/2011/07/07/renderman-shader-editor-alternative-for-linux-opengl-and-glsl/)
(The link URL contain the word "renderman", which of course is something different.)

RenderMonkey was in my view a fantastic tool for prototyping and writing shader code, but the project has been discontinued for quite a while and the application is not for linux.

Now I'm thinking of a use for my simple graphics engine and one idea is to create an open source alternative for linux (initially). One reason for the abandonment of such IDE's/tools was, if I've understood it correctly, that the lack of fixed functionality (and variables) in modern OpenGL makes it difficult to create a general tool. More specific, since the general vertex attributes are arbitrary nowadays, the application does not know what to expect. The stream mapping in RenderMonkey 1.82 seems to work good for common cases (except for the TEXCOORD, which I haven't got working), and maybe there are variations of their mapping solution which could work.

I'm curious about how interesting this idea is to you. Would it be a project worth of further investigation and something to pursue? Why or why not?

Please tell me your thoughts and if you follow my link above you can vote in a poll.

The Little Body
07-21-2011, 02:54 PM
100% of votes are "Yeah! Do it!" :)
(but ok, it's only 10 votes ...)

This can effectively to*be a good thing, so I'm OK for to work with you for to implement this on the Linux platform :)
(I think too that this can be a good thing to implement this for the Android platform ...)

I have discovered this link http://cumbia.informatik.uni-stuttgart.de/glsldevil/ that seem me already really advanced :)

Linsnos
07-22-2011, 03:45 AM
Great!

Thank you for your feedback. Yes I know, not so many votes yet. The number of positive votes would have to be one or a couple orders of magnitude greater than that before I believe the effort would be worth it.
I am very thankful for everyone who has voted so far!

Don't hesitate to be critical about my idea. I honestly want your opinion.

glsldevil seems like a promising software with some great features. I haven't heard about it before and hopefully it will evolve!
It seems to have a different purpose though. I'm aiming of something more like a sandbox in which you can experiment and create, as opposed to the "inspecting" and analyzing approach.

As for other platforms, it might be a good thing to do an evaluation of the possibilities. If it is simple to port, it should be ported.
I use CMake for my graphics engine project, which might make things easier.
In my view, this is a later question, since one has to have something to port first.

Anyway, I look forward to further reactions and thoughts.

thokra
07-22-2011, 04:54 AM
The absence of a recent tool supporting current OpenGL mechanisms and practices has pained me for a long time now.

I also started a little shader editor for Linux and I will integrate my renderer which I'm currently developing as part of my diploma thesis. This will enable authoring shaders for a wide range of purposes with, for instance, automatic, customizable shadowmap generation, automatic gbuffer setup for deferred shading and combination of several shaders into one.

One project which has been intriguing is Lumina. It has been around for a while and can be reached at

http://sourceforge.net/projects/lumina/

I can't really confirm that glslDevil is a suitable replacement for RenderMonkey as it is more closely related for instance to gDEBugger, being a GLSL debugging utility. You can edit shaders but I would hardly call it an IDE.

Anyway, I think good shader authoring tools supporting recent GLSL version will definitely be received well.

The Little Body
07-22-2011, 04:33 PM
glslDevil is effectively more closely related to OpenGL debugging utility
(it display the opengl activity generated by an opengl program)
=> so effectively, it cannot to be used as a RenderMonkey inspired GLSL editor for linux :(

I have discovered the Lumina project with your link
=> I attempt actually to install it on my Linux Fedora box, but I have a problem with qmake ("bash: qmake: command not found") ... and always the same problem after somes commands such as 'yum install qt* qmake* --skip-broken' :(

Linsnos
07-23-2011, 12:56 AM
You could try to install the full Qt4 SDK (i.e download the installer from Nokia). I installed it in my home directory. For a brief explanation of my solution you could check linsnos (http://www.acc.umu.se/~linsnos/?q=node/32), for a post I wrote about it.
Basically, I use kalternatives to chose the right version of qmake in my system.

Linsnos
07-23-2011, 01:01 AM
Nice! Thank you for the link. I installed and tried Lumina and it seems really good.
Unfortunately I get segmentation fault as soon as I try any example. It might be a configuration issue. I will look into that.
The source is from september last year. I hope they continue the development.

Your own project seems really exciting too. It would be great if you publish your results later on.
Good luck!

The Little Body
07-25-2011, 02:29 PM
Hi,


I begin to work about a lightweight process that alloc shaders, detect shaders modications and delete them.

I want that it automatically detect the modication of a shader file and automatically recompile the shader in OpenGL with the new file version (because at this moment, the shader used by OpenGL is the old version).

I think that it's better if this little part can be handled by an little API, because with an API we can easily use it in a bigger project such as a "RenderMonkey like for Linux" **and** this can too to be easily used on smalls and multiples lighweights process

The Little Body
07-25-2011, 06:06 PM
I can now detect files modifications in realtime using dnotify in Linux :)

=> I see how to integrate this with the OpenGL vertex/fragment shaders compilation chain for to can automatically apply a reload/recompilation of a shader program when one of its vertex/fragment shader or subshaders file is modified.

Linsnos
07-29-2011, 10:02 AM
Yes an autobuild feature could surely be appreciated in many places. I think it is good if the user can choose if it should be on or off in an application. I learned from wikipedia that dnotify has been obsoleted by inotify. I don't know if that information is relevant for you.

Linsnos
07-29-2011, 02:54 PM
I have noticed some need for an application such as the post title suggests, and I lean towards making an effort.
Maybe there are more channels I can use to investigate the interest?

In the fall I will do my masters thesis and I will investigate if there are any companies where I live which would be interested in such an application. Of course, most of them should already have in-house tools, but anyway.

I appreciate all feedback I can get!

The Little Body
08-01-2011, 04:56 PM
Yes, file modifications are detected with dnotify ... :(



#define _GNU_SOURCE
#include <fcntl.h>
#include <sys/stat.h>
#include <stdio.h>
#include <errno.h>
#include <signal.h>
#include <stdlib.h>
#include <string.h>


int fd=0;
char *dir=NULL;
char *slashPtr=NULL;

struct stat statBuf;
struct sigaction action;

int directorychanged=0;
char splitFilename[128];
char filechecked[127];
time_t modifiedTime;

int isrunning=0;
int filechanged=0;


void EventHandlerFunc( int sig )
{
// printf("This is the event Handler when the ./ directory is modified \n" /* , filechecked */ );
directorychanged = 1;
}

void DelayedActionToFileChange()
{
printf("Delayed action after a modification to %s \n", filechecked);
filechanged = 0;
}


int InitDetectChange( int argc, char *argv[] )
{
/* Find directory the file is in, or assume the current directory */
strncpy( splitFilename, argv[1], 127 );
strncpy( filechecked, argv[1], 127 );
if( (slashPtr = rindex( splitFilename, '/' )) == NULL )
{
dir = ".";
}
else
{
*slashPtr = 0;
dir = splitFilename;
}

/* Set up the signal handler */
action.sa_handler = EventHandlerFunc;
sigemptyset( &amp;action.sa_mask );
action.sa_flags = SA_RESTART;
sigaction( SIGRTMIN, &amp;action, NULL );

/* Open the directory the file is in */
if( (fd = open( dir, O_RDONLY )) < 0 )
{
printf( "Cannot open %s for reading : %s\n", dir, strerror(errno) );
exit( -1 );
}

/* Choose the signal I want to receive when the directory content changes */
if( fcntl( fd, F_SETSIG, SIGRTMIN) < 0 )
{
printf( "Cannot set signal : %s\n", strerror(errno) );
exit( -1 );
}

/* Ask for notification when a modification is made in the directory */
if( fcntl( fd, F_NOTIFY, DN_MODIFY|DN_MULTISHOT ) < 0 )
{
printf( "Cannot fcntl %s : %s\n", dir, strerror(errno) );
exit( -1 );
}

if( lstat( filechecked, &amp;statBuf ) < 0 )
{
printf( "Cannot lstat %s : %s\n", filechecked, strerror(errno) );
exit( -1 );
}
modifiedTime = statBuf.st_mtime;

return fd;
}


int DetectChange(char *filename)
{
if( lstat( filename, &amp;statBuf ) < 0 )
{
printf( "Cannot lstat %s : %s\n", filename, strerror(errno) );
exit( -1 );
}

// If the modification time has changed, the file has been altered
if( modifiedTime != statBuf.st_mtime )
{
directorychanged = 1;
filechanged = 1;
modifiedTime = statBuf.st_mtime;
// printf( "File %s has really been modified since the lastest call\n", filename );

}else{
// directorychanged = 0;
filechanged = 0;
// printf( "File %s hasn\'t been modified since the later call\n", filename );
}

return filechanged;
}

void PrintUsage(int argc, char **argv)
{
if( argc != 2 )
{
printf( "Usage: %s filename", argv[0] );
exit( -1 );
}

if( lstat( argv[1], &amp;statBuf ) < 0 )
{
printf( "Cannot lstat %s : %s\n", argv[1], strerror(errno) );
exit( -1 );
}

if( ! S_ISREG( statBuf.st_mode ) )
{
printf( "%s is not a regular file\n", argv[1] );
exit( -1 );
}
}


int main( int argc, char *argv[] )
{

PrintUsage(argc, argv);

isrunning = InitDetectChange(argc, argv);

while( isrunning )
{
/* This demo has nothing to do, so just wait for a signal */
sleep(10);

/* Check the flag which indicates the right signal has been received */
if( directorychanged )
{
if( DetectChange(argv[1]) )
{
sleep(1);
DelayedActionToFileChange();
}
}
}

return 0;
}


But this use lstat( filechecked, &amp;statBuf ) vs modifiedTime too :)
=> if necessary the dnotify part can to be canceled ...
(but perhaps with a %CPU increase because it limit really the number of calls to the DetectChange() func ...)

This is not OpenGL code, this produce only a little executable that detect when the file in argument is modified.

I think to use separates (but linked) tasks for

1) edition of shaders

2) detection of changes in a vertex/fragment shader file

3) [re]compilation of shaders [that are changed]

4) execution of a OpenGL task that show edited shaders in action

The previous code can already be used for to implement the part 2) and the part 3) is't too difficult to make :)

But Ok, if the part 4) can certainly to be make without too difficulties, I think that the really hard task is to make the editor ... :(

przemo_li
08-17-2011, 03:21 AM
Put your code in git repo (or any other dvcs), under FLOS license and there will be folk who will help.

Linsnos
08-27-2011, 11:42 PM
This thread has been viewed quite many times now, but the comments are sparse.

Please post your thoughts if you have any. It would be great with lots of opinions (written) about the idea. :) Pros, cons, decisions to make, hurdles to overcome, usefulness etcetera.

In the next month (or two) I will decide if I'm willing to go 100% on this or not.

Linsnos
11-29-2011, 06:51 AM
A lot of readers but no feedback.
Maybe the post title is misleading.
Anyway, I take it the lack of response is a sign of little interest in the idea so will not proceed further at this point.
Maybe the software already out there is good enough and evolving.

ZbuffeR
11-29-2011, 09:37 AM
Well it is interesting but I can not access your original post ?
Did you add your tool to the opengl wiki, to increase its visibility ?
For example here :
http://www.opengl.org/wiki/Category:OpenGL_Shading_Language

And submit it to the front page of OpenGL.org

Linsnos
03-14-2012, 02:50 AM
Sorry for late reply.
I never started development of that tool. The interest seemed a bit low.

_arts_
04-06-2012, 03:49 AM
It takes you 3 months each time to answer any of the replies here. Of course interrest is low under this condition.

PS: I know you, like many others, are certainly a lot busy, but you can't do prospection and think it can live alone. Prospection is almost a full-time job.

Regards.