OpenGL playfield

Development Coding synfig
#1

Hi!

First of all, sorry, I don’t have yet any screenshot :slight_smile:.

Summary: If you haven’t followed the post about changing the GUI to QT (here), I’m trying to do an OpenGL rendered playfield, so we can boost Synfig.

I’ve a few (well, just one for now) questions.

Should I maintain the old playfield as an option? Or if anyone want the old (or the new) just have to compile again? I’ve just sneaked a bit in the code, and it’s VERY GTK dependent.

I want to maintain the old playfield as an option, and make playfields as options (just in case someday we add a DirectX one, for example), but that means changing A LOT of things (well, maybe just only the renderers and the workarea, but that’s a lot of files, maybe 8 without the headers). Don’t know if that’s intended / wanted / tolerated, etc…

P.D. I don’t know if that post has to be here. If not, kindly moderator, please move :slight_smile:

#2

I think that the best option for the moment is to keep the old playfield and add the new one using environment variables like #ifdef STUDIO_USE_OPEN_GL bla bla. Probably it would make the code more unreadable but it should keep it functional. Also it would allow to use the old playfield for the output render because, as I mentioned in the other post, it might be possible that OpenGL doesn’t render accurately all the effects to the final output and we have to continue using the old renderer.

Exactly. Optional renderers would be the good choice.

Regarding to the modification of a lot of files I think that it would be good if you use the git repository that dooglus (our only and main developer) keeps for large modifications. Currently we (he mainly) are doing a bone system in synfig. You should be able to use that repository to keep track of large chunk of files and also to allow others to pull from it and test the branch in other machines. Once the modification looks fine it would be a big commit (stashing it first) to svn. Unfortunately dooglus’s hardware is mostly dead so he barely can connect to internet lately and the bones development has been momentary discontinued.
I don’t know if you have a good hardware but dooglus was using my pc (quadcore 2.66 GHz 8 GB RAM, that has Ubuntu amd64 installed) remotely for quick compiling and testing. We have made a binary of synfig and synfigstudio for each 3 or 5 commits so we can find quickly where the bug was introduced in the past. I’ll be glad to share my resources with you too.

I believe that there is a open account for guests in the repo to allow others to commit changes. Try that first, before start doing any code.

Here is the address:
repo.or.cz/w/synfig.git

I’ll move the thread to Coding Synfig forum, if you don’t mind.

This is exiting! :slight_smile:
-G

#3

Hey,
I’ve been talking to dooglus and he told me to allow you to push to git repo.
Just open an account here:
repo.or.cz/m/reguser.cgi
and email dooglus to let him know your username to allow it to write on synfig repository.

mailto: dooglus@gmail.com

-G

#4

Yes, that’s the way I’m doing it right now. And yes, the code IS more unreadable :stuck_out_tongue: (at least the renderers, that have a few nested ifdef’s), but I think I can add it as an option when I’ve finished with it, so no problem here :slight_smile:.

Ok, thanks a lot! Also, I mostly prefer using GIT than SVN :slight_smile:. It’s way better (in my humble opinion), and you can commit offline. Great!

#5

My God! this is promising!

Here is a zoomed view of a sketch done usigng opengl libraries and using gtk libraires:

GTK libraries:
original1.png
OpenGL libraries:
gl1.png

The checkboard of the bottom of the canvas is not rendered already but, do you see the difference?

Thanks Uoimae!!! :slight_smile:
-G

#6

You’re welcome, Genete :wink:.

#7

Wait-wait-wait! Is it images produced by synfig renderers?
I guess now I know why genete was silent lately - you talking with Uiomae about code? :wink:
Uiomae, that’s great!!! Superb!

#8

Thanks a lot, Zelgadis!

I’m doing a “development update”. This is the current state of the renderer:
snapshot1.png
Don’t you like the new ducks? I LOVE them :stuck_out_tongue:

Anyway, I’m progressing to add OpenGL as full renderer. As dooglus told me, it’s better to add some functions to the layers to render with OpenGL instead of the current renderers. Currently, there is a “Layer::accelerated_render()” function called for every layer. I’m going to add “Layer::opengl_render()” for each of them too. But previously, I’m going to rename “Context::accelerated_render()” and call it “Context::render()”, because it iterates over layers and call the needed methods, but this time it’s going to call “Layer::accelerated_render()” or “Layer::opengl_render()” depending on selected renderer. I’ve already added a variable to Target base object to store the current renderer, and an option to the CLI to select the renderer. Option in studio it’s on its way!

Anyone has another different / better idea? Maybe questions? Thanks in advance!

#9

It all looks very cool…

G.

#10

Progresses:

regions-sr-screen.png
regions-sr-screen.png726×590 55.9 KB

regions2.png

regions-sr.png

Thanks Uiomae! And good luck! :smiley:
-G

#11

Yes Thank you very much Uiomae!! :mrgreen:
This OpenGL renderer will be necessary to work on really big/complex project…

#12

Amazing work!
This will push Synfig towards the end users so much, because it will become WYSIWYG app! No need to wait for render to see final result in motion!

#13

I can’t wait :smiley:

#14

Hi again. I wanted to know what card do you have in order to focus the new features a bit. Also, I need to know the capabilities of your card. So, in order to do that, I need one of this things:

If you run Linux:

  • Run the glxinfo utility, and send here the output. To do that, you can do in the console: “glxinfo > glxinfo.txt” and attach here the glxinfo.txt file
  • Run the glewinfo utility. To do that, install the package glew-utils (in Debian based systems, at least) or glew (in Fedora systems, thanks Zelgadis) and run “glewinfo > glewinfo.txt”

If you run Windows:

  • Run the glewinfo utility. Install the glew package (search on Google for the glew webpage) and run “glewinfo > glewinfo.txt” on a console.

If you run MacOSx:
I don’t really know about this one, but I think glew also works on MacOSX.

Anyway, just attach the files and say what system are you using.

Thanks a lot!

#15

Fedora 7 and Fedora 10.
You need to install glew package to get glewinfo command for that system.

xorg-x11-drv-nvidia-177.82-1.fc10.x86_64
glxinfo.txt (25.8 KB)
glewinfo.txt (114 KB)

#16

For the OS : Debian unstable. More or less up to date. Well, maybe less (if you want to know the version of a specific package, ask ^^) 2.6.22-1-amd64
glewinfo.txt (114 KB)
glxinfo.txt (10.2 KB)

#17

This is my work laptop

$ uname -rmo
2.6.26-1-686 i686 GNU/Linux
glewinfo.txt (113 KB)
glxinfo.txt (5.03 KB)

#18

My glewinfo - Radeon 7200 on WIndows XP

Chris
glewinfo.txt (144 KB)

#19

$ uname -rmo
2.6.27-11-generic x86_64 GNU/Linux
:smiley:
-G
glewinfo.txt (114 KB)
glxinfo.txt (21.2 KB)

#20

Debian lenny with an intel card:

00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)

glxinfo.txt (5.01 KB)
glewinfo.txt (115 KB)