Page MenuHome

blender 2.8: OpenGL: New bezier curve shader and use in node editor.
Needs ReviewPublic

Authored by Krantz Geoffroy (kgeogeo) on Oct 13 2016, 11:17 PM.

Details

Summary

It's maybe useless but I've learned a lot and it was fun to do!!!
I really done know if there a benefit to do this with geometrie shader, can someone test with a profiler or something?
Anyway all the link in node editor are done with new immediate mode.

Diff Detail

Event Timeline

Krantz Geoffroy (kgeogeo) retitled this revision from to blender 2.8: OpenGL: New bezier curve shader and use in node editor..
Krantz Geoffroy (kgeogeo) updated this object.

Pass the handle curve with attribut no more whit uniform.
it will be better so I think.
Is there an interest for this patch? If yes I will look to change the draw method of f-curve too.
Thanks

Mike Erwin (merwin) edited edge metadata.EditedOct 14 2016, 11:21 PM

Is there an interest for this patch? If yes I will look to change the draw method of f-curve too.

It's certainly interesting. Still reading it...

Note that the #version 120 stuff is for Mac, which has geometry shader support only through the EXT_geometry_shader4 extension. Might be better to save geometry shaders til after core profile is ready. Then all platforms can use #version 330.

Hi, I think it's not done good enough to pay attention on it for now, but I learn. ;-)
So I want to make a bezier shader who can draw directly, bezier curve, shaded or not, behind another curve with another line width (dotriple) and finaly arrow.
So only 1 call for a complet curve.
Then when done I will try to rearange the node_tree_draw function to draw all the line in one time.
Is it a good plan for you?

Passing in start + end points and getting a fancy curve drawn would be awesome!

My goal right now is to get us to GL core profile though, which means getting rid of legacy immediate mode & matrix stacks. Less awesome, more urgent.

Krantz Geoffroy (kgeogeo) edited edge metadata.

Now all the bezier node curve are drawn in one call.
I have a problem still.
I use glEnable(GL_MULTISAMPLE); before I draw and disable after, it give exactly the result expected.
But it i move my mouse outside of the area then the antialising go down or glitch a little bit. Even when I
stay in the same area and wait for tool tips box appear, it's doing the same.
For sure I miss something but really don't know what, I search since 3 days and it's starting to turn me crazy.... ;-)))
I wil try to post picture of the problem.
Thanks

I don't know why that would glitch. You enable GL_MULTISAMPLE before drawing and disable right after. *shrugs*

Could reuse gpu_shader_2D_smooth_color_frag.glsl instead of making a new fragment shader.

Result looks great, btw!

git update... pfff it's hard... Any good method to do this without breaking every think each time I merge??
Also make the change to use gpu_shader_2D_smooth_color_frag.glsl

Krantz Geoffroy (kgeogeo) updated this revision to Diff 7680.EditedOct 23 2016, 12:03 AM

fix build error after deleting file

Hi,

kgeogeo: as we talked on irc, I applied your patch, confirmed the glitch and investigated. You mentioned it only happened with triple buffering, that was a key information, thanks. With triple buffering Blender saves the screen areas as textures and only redraws on top of them specific elements, like commented here:

line #359 in source/blender/windowmanager/intern/wm_draw.c:

/****************** draw triple buffer ********************/
/* - area regions are written into a texture, without any */
/*   of the overlapping menus, brushes, gestures. these   */
/*   are redrawn each time.                               */

I thought that might be the root of the problem. I tried a few things that didn't work, then just forced a redraw of the window (content, without header, etc.) portion of the Node Editor in the function wm_method_draw_triple() (line #506).

This is the code I added there (source/blender/windowmanager/intern/wm_draw.c) at line #572:

	for (sa = screen->areabase.first; sa; sa = sa->next) {
		CTX_wm_area_set(C, sa);

		if (sa->spacetype == SPACE_NODE) {
			for (ar = sa->regionbase.first; ar; ar = ar->next) {
				if (ar->regiontype == RGN_TYPE_WINDOW) {
					CTX_wm_region_set(C, ar);
					ar->do_draw = true;
					ED_region_do_draw(C, ar);
					ar->do_draw = false;
					CTX_wm_region_set(C, NULL);
				}
			}
		}

		wm_area_mark_invalid_backbuf(sa);
		CTX_wm_area_set(C, NULL);
	}

As I said, it just forces redrawing the area where the nodes are being drawn, it's a quick hack for testing purposes. Here this fixed the glitch, please test to confirm.

But if this is where it must be solved, then it's not a problem in your code and a proper solution needs help from mervin, dfelinto (this would need to be solved for multiview, too), possibly other devs responsible for this area, which is a fundamental one impacting Blender's performance.

Maybe it's better to only redraw the node connections (expose a function to handle that) or write code in Blender to represent lines as polygons (not trivial if looking for a good solution to draw smooth lines in general), maybe a shader can substitute the use of multisampling, ...

Hi again,

Two comments about the patch:

  1. In source/blender/editors/space_node/node_draw.c: that should be glDisable(GL_MULTISAMPLE); , too.
  1. You need to free the shader in source/blender/gpu/intern/gpu_shader.c, take a look at the function GPU_shader_free_builtin_shaders(), line #925.

I use now gpu_multisample() because it seems problem can happen problem with nvidia and linux, (my case by the way).
Free the shader too, thanks Ianwill to point this out.

Now I will try your solution.
thanks again

Soooo, endly, I can confirm it's solving the problem yes. Thanks a lot.
But now I think that we can say that it's looking like a bug or limitation no?? mervin?

I I've try to smooth the polygon inside the geometry shader but it's using to much vertices, there a hardware limitation on emitvertex, by me it 128 vertices
by GS. For a smooth segment i would need 8v , so I only can handle 16 segment, but in the initial code we need 24. So I'm far above GPU limitation.

Else maybe in the frag shader?? mervin?

One question still, ok in the code it doesn't redraw the region, but why it change??
I mean if it only redaw the active area why it touch the texture of space nodes??

thanks for all again

But now I think that we can say that it's looking like a bug or limitation no??

From what I read here, yes a limitation. We'll keep this in mind while implementing the viewport FBOs/buffers/plates system. The OpenGL upgrade (including T49043) is just one part of Blender 2.8's redesign.

I I've try to smooth the polygon inside the geometry shader but it's using to much vertices, there a hardware limitation on emitvertex, by me it 128 vertices
by GS. For a smooth segment i would need 8v , so I only can handle 16 segment, but in the initial code we need 24. So I'm far above GPU limitation.
Else maybe in the frag shader?? mervin?

Yes we can make a fragment shader that draws thick lines (as a tri-strip) with one inner color and a different outer color. Fragment shader can also do the antialiasing and not rely on multisampling. See the POINT_OUTLINE_SMOOTH shaders which do something similar.

24 segments would need... 50 vertices. Well below limits!

Soooo, endly, I can confirm it's solving the problem yes. Thanks a lot.

My pleasure, thanks for confirming.

One question still, ok in the code it doesn't redraw the region, but why it change??
I mean if it only redaw the active area why it touch the texture of space nodes??

From what I read, multisampling can use the window / context created to be used by OpenGL, where the pixels will be sampled from the allocated "back" buffer (the one drawn to but still not visible in double or triple buffering) or an FBO (frame buffer object) that you set yourself in the code. As a quick test I tried naively to force multisampling when the textures were being created, but it didn't work, so maybe the pixels are being written directly to textures and there's nowhere to sample from for multisampling, so this step is ignored. I didn't investigate further. Using an FBO might be a nice solution, since then you create a buffer to be sampled from. There was an unrelated comment about using one in another file I mentioned to you on irc yesterday, even, from what I recall and now merwin also said they plan to use that more for Blender 2.8. The first link below has code related to this.

Relevant links:

Krantz Geoffroy (kgeogeo) updated this revision to Diff 7703.EditedOct 27 2016, 4:57 PM

I disable multisampling and I try to do it in the fragment shader, work ok but not perfect.

work ok but not perfect.

I think the result looks good! What can be improved?

Hi Guys,

Sorry for a slight off topic question but im just starting with Blender code. Ive downloaded the latest snapshot from git for 2.8 and compiled on vs2015 for win 64 bit. Everything compiles fine, Im then copying the exe over to a latest master branch compile just to test. Is this the best way? or is there a way to generate a complete Blender release with all normal dlls and addons directory etc you normally get in an official release?

Anyway when I run the 2.8 test EXE build blender loads up but im missing all menus and prefs, even running user prefs in menu just brings up a blank grey box.

After loading in a scene this is the result I get,

Is this expected behavior for this branch as so heavily in development? Just need to know before starting on viewport opengl fixes.

Cheers J

Notes about small implementation details:

source/blender/editors/space_node/drawnode.c
3385–3387

Return true or false.

3422–3425

I recently added Batch_Uniform1b for booleans. Will add same thing for immediate mode so you can say this:

immUniform1b("drawarrow", drawarrow);

3531–3533

Same here, return true or false.

source/blender/editors/space_node/node_draw.c
58

Is this needed? I don't see any new code that uses it.

source/blender/gpu/CMakeLists.txt
133

Name this _geom.glsl for consistency with other shaders. I'm adding some geometry shaders too.

source/blender/gpu/shaders/gpu_shader_2D_bezier_curve_frag.glsl
3–6

Since this is tied to a geometry shader, we don't need to worry about GLSL 120 (which is only used for legacy Mac OpenGL).

Geometry shaders will not run on Mac until we finish the transition to core profile. After that, all platforms will be at #version 330 and we can take this #if junk out of all the shaders!

source/blender/gpu/shaders/gpu_shader_2D_bezier_curve_geo.glsl
113 ↗(On Diff #7703)

Can this go in the "if (drawarrow" block below?

source/blender/gpu/shaders/gpu_shader_2D_bezier_curve_vert.glsl
2–4

Can remove version 120 support here too.

Krantz Geoffroy (kgeogeo) updated this revision to Diff 7706.EditedOct 27 2016, 10:50 PM

Almost all changes are done, only ont for immUniform1b... I'm afraid to git pull again and to redo everything again.
So first I've to learn git more or maybe you have a magic command???

The problem is here


When the lines are almost strait, it's fu**** jaggy.

... redo everything again.
So first I've to learn git more or maybe you have a magic command???

Don't want you to have to redo anything! Keep immUniform1i, that's fine.

Does git stash not work for you?

not sure, almost every time that I make git pull I've go to a problem.
Is this doc still OK.
https://wiki.blender.org/index.php/Dev:Doc/Tools/Git

ok I think I manage to update git, but I don't find immUniform1b.
You have not done it yet, isn't it??
Anyway its up to date now (I hope) ;-))

Nope not yet. I'm finishing some things for the Blender conference!

Glad git was more forgiving this time.

Oh well, clearly even though you devs have put out a call to action for people to help convert pre 3.3 opengl you dont want to help newbies contribute.

Appreciated. Thanks for the help.

I think it's not the good place to ask...
Anyway I have had the same on and some it with building with "make" in the terminal, it installing the python stuff. But I am under Linux not windows so I think it will not help.
Better ask on it #blendercoder or on the mailing list

Oh well, clearly even though you devs have put out a call to action for people to help convert pre 3.3 opengl you dont want to help newbies contribute.

Hey just saw your message. I use "make 2015 debug lite" and sometimes "make 2015 full" on Windows. After that you can run blender.exe from blah/bin/Debug or blah/bin/Release.

Aghhh, Really? Like i need help to create a working build through make? What i was asking is the behavior i exampled above was normal for this 2.8 branch with having no interface menu's.

Point being if that's not normal for this build i would re-install 2013, Such a bunch of tossers. Interest in helping 0% Now.

And i really could of helped here, But if you want to do things in the wrong way i guess it's a Blender all over.

Aghhh, Really? Like i need help to create a working build through make? What i was asking is the behavior i exampled above was normal for this 2.8 branch with having no interface menu's.
Point being if that's not normal for this build i would re-install 2013, Such a bunch of tossers.

No the behavior you describe is not normal, UI should be intact. I'm using MSVC 2015 and builds of blender2.8 work fine. After building it should have its own Python folder just like a downloaded version. No need to copy the exe anywhere.

Maybe try scrapping the existing build folder(s) and build from scratch.

There's also a "make release" target but I don't know the difference between that and "full". AFAIK either one will give you a working build complete with DLLs etc.

Well that kind of response would of been good to start with, Im still not interested any more. You should be more open to new devs, Ive already done a good few fixes undone on your list.

I could upload them or just say, Wellllllll ive got more important things to do that actually make me money. All the Best

@James W E Bird (3dLuver) it is not that we are not really willing to help it is just that all the developers are busy right now working on things for the blender conference this weekend. After that developers are going to be a lot more helpful.

Krantz Geoffroy (kgeogeo) updated this revision to Diff 7720.EditedOct 31 2016, 9:17 AM

hi,
I rename some variable to be more clear I hope, and play to adjust value to have a smoother line.
I have to say that I'am pretty happy of the result, the key what to multiply fwidth.

ps: I've look your presentation in BCON, was great, nice job.

Krantz Geoffroy (kgeogeo) updated this revision to Diff 7737.EditedNov 5 2016, 9:23 PM

Hi,
I've added somme stuff, it's now possible to draw straight line, I use it to draw the line between 2 reroute node, I find it better...
the number af segment change now according to the distance, simple code can find better for sure if you have an idea.
Rework some code too, the normal of the middle arrow point was wrong, same as every normal of bezier curve.
I was using the norm before and after the point, but the one before was already calculate, so the result was not the one expected.

ps: I've also look into the graph draw code, it will be hard to use this shader, possible for the simple part, when a curve use only constant, linear or bezier, but when we use modifier or complex function like sin or quadratic it we be hard, mabe not possible because of the sample methode. no?

fix the last vertex normal.
sorry for the noise. ;-((

adapt the patch to the recent gpu_shader.c modification.

Still interested in this patch! Just waiting for the right time, when geometry shaders work on all platforms.

no problem, take your time...

Hey @Mike Erwin (merwin) since we are already assuming OpenGL3.3 for 2.8 can we merge this in? Or at least with some #ifdef. No reason for the patch to get too old :)

Hey @Mike Erwin (merwin) since we are already assuming OpenGL3.3 for 2.8 can we merge this in? Or at least with some #ifdef. No reason for the patch to get too old :)

Yes, that's a good idea! Right now it's safe to assume GL 3.3 on Windows only. In general we'd need to do this:

if (GLEW_VERSION_3_2)
   new bezier drawing function
else
   old bezier drawing function

And mark the old drawing functions as deprecated. Could even #ifdef them out on Windows.

source/blender/gpu/intern/gpu_shader.c
605

Not part of this patch, code just got out of sync.