How do I use stencil textures for outlining shapes?

Hello, everyone!  I hope you're all doing well.

After 20 years of graphics I finally jump from fixed-function to programmable pipeline.

In my existing project (https://github.com/MarginallyClever/Robot-Overlord-App/) I am using a stencil buffer and an offset-by-normal fragment shader to highlight selected objects.  Works great, doesn't look very good, as described with pics in https://github.com/MarginallyClever/Robot-Overlord-App/issues/138

Having read https://open.gl/depthstencils and https://alexanderameye.github.io/notes/rendering-outlines/ I'd like to use the Jump Flood Algorithm to make really nice outlines.  I also found https://github.com/kiwipxl/GLSL-shaders/blob/master/outline.glsl

Currently I am using the jogamp-fat 2.4.0.  I think this was done so that the natives could be repacked for distribution correctly?  It's been a long time.  In practical terms it means that I can't access a bunch of internal texture formats like GL_STENCIL_INDEX8 or GL_DEPTH24_STENCIL8 because

> Caught GLException: format 0x8d48 not supported [yet], pls notify the maintainer in case this is our bug.

My project is large so I have tried to write some smaller tests.  You can find them in branch https://github.com/MarginallyClever/Robot-Overlord-App/tree/new-outline at
com/marginallyclever/robotoverlord/renderpanel/OpenGLTestOrthographic.java
extended to com/marginallyclever/robotoverlord/renderpanel/OpenGLTestPerspective.java
extended to com/marginallyclever/robotoverlord/renderpanel/OpenGLTestStencil.java

the last one is the item I'm trying to make work.  At this stage all I'm trying to do is display the contents of the stencil texture before I move on to tackling JFA.

I have tried to attach RenderDoc.  I must still have some active FF in there because it flatly refuses to work with me.

What I'm looking for, please, is a tutorial/demo that draws a single triangle in ortho projection, captures the stencil to texture, runs JFA, and outlines the triangle.  I feel confident if I had one working model I could carry the ball the rest of the way.  GL3 would be awesome, GL4 also works.

Thank you!

Hi 'John Doe' (forgot your name from back then),

first off, the stencil buffer thingy is indeed something left-over from
fixed functionality and it is not (a) free (shader pipeline) at all.

Lately I used alpha and discard, but whatever .. it shall work.

+++

If you don't mind, please drop a full debug output piped to file,
see <https://jogamp.org/wiki/index.php?title=Jogl_FAQ#Detailed_Debug_Log>.
Then please attach the file to your reply.

This shall disclose quite a few things including the full stack trace.

Then we also might want to have the while platform info you are running,
see <https://jogamp.org/wiki/index.php?title=Jogl_FAQ#JOGL,_Platform_and_OpenGL_Version>.

Both infos are referenced in the wiki page of our <https://jogamp.org/wiki/index.php?title=Jogl_FAQ#Bugreports_&_Testing> .. I know, old times.

Finally, while having shown us the code base of yours, please also add a line
how you launch (which class w/ arguments). That would help a more easy reproduction of things.

+++

From memory, it might be so that we still have to add the ole dirty stencil buffer
to our FBO object? Not sure, but the above info will show.

one note re stencil shader pipeline costs (not free, but still useful)

My guess as to why this didn’t help overall was not really the cost of the branch itself, though that was part of it, but rather the high divergence it caused. The short version is since every pixel’s shader invocation is going to be stopping at a different point, the GPU couldn’t make as efficient use of this optimization. The GPU runs multiple pixel shaders in batches, and all invocations in that batch cost as much as the most expensive pixel. So while some pixels may have been potentially much cheaper, they were still waiting for the more expensive pixels to finish. The result just happens to even out.

From the inner linked nice article

The Quest for Very Wide Outlines
<https://bgolus.medium.com/the-quest-for-very-wide-outlines-ba82ed442cd9>

Reminds me of our AA strategy for low DPI screens for Graph ...
The one still not yet implemented way is indeed the outline extrusion,
aka widening of the pixel surface to perform AA.
I intend this by using normal and distance indeed .. while setting up the shapes (CPU).
Just a little brainstorming.

You're right, I left out some basic stuff.  My ticket-fu :(

Windows 11, JDK 15.0.2

I didn't have any instance of "etc\test_dbg.bat" on my computer or in the jogamp jar file.  I found https://jogamp.org/deployment/jogamp-current/archive/jogamp-all-platforms.7z, extracted the files, clicked the bat in windows and it generates a log file that says

   Error: Could not find or load main class com.jogamp.newt.opengl.GLWindow
   Caused by: java.lang.ClassNotFoundException: com.jogamp.newt.opengl.GLWindow

same results for test.bat.  I was able to programmatically run `JoglVersion.getInstance().toString()` to get

-----------------------------------------------------------------------------------------------------
Package: com.jogamp
Extension Name: com.jogamp
Specification Title: JogAmp Java Bindings Specification
Specification Vendor: JogAmp Community
Specification Version: 2.4
Implementation Title: JogAmp Java Bindings Fat Jar
Implementation Vendor: JogAmp Community
Implementation Vendor ID: com.jogamp
Implementation URL: http://jogamp.org/
Implementation Version: 2.4.0-rc-20190410
Implementation Build: 2.4-b916-20190410
Implementation Branch: origin/master
Implementation Commit: 8c4e3c5abe2dd2d6cdebe7de93a942075bf72762
Implementation SHA Sources: null
Implementation SHA Classes: null
Implementation SHA Classes-this: null
Implementation SHA Natives: null
Implementation SHA Natives-this: null
-----------------------------------------------------------------------------------------------------

The FAQ mentioned GlueGenVersion (which produced the same thing) and Platform (Which didn't follow the convention or have a getInstance().toString())

I went back to the extract root with CLI and ran "etc\test_dbg.bat".  Finally! FAQ instructions could be a lot clearer.

test_dbg.zip

Here is the other log file, too.test.log

Oh I see, the instructions in your message were sort of in reverse order.

The main() from each class
com/marginallyclever/robotoverlord/renderpanel/OpenGLTestOrthographic.java
com/marginallyclever/robotoverlord/renderpanel/OpenGLTestPerspective.java
com/marginallyclever/robotoverlord/renderpanel/OpenGLTestStencil.java
can be run to show basic orthographic drawing, basic perspective drawing, and finally perspective with stencil (failing).

I don't know what you mean by "first off" and "alpha discard".  If you have some way to achieve the effect I'm looking for, please let me know.  I'm happy to skip the stencil buffer completely if I don't need it.

Thank you!

Please can you at least use an LTS version? We won't test all Java versions from 8 to 20.

Sven, why does the implementation URL still use http instead of https?

So... if anyone can tell me how to get the effect I'm going for, please do.  I'd really love to close my local ticket.

Thank you!

etc/test_dbg.bat is here:
https://jogamp.org/cgit/jogl.git/tree/etc/test_dbg.bat

You still use an obsolete release candidate.

Now it would helo, if you could run your application with the debug flags,
i.e. `-Djogl.debug=all` maybe even
`-Dnativewindow.debug=all -Djogl.debug=all -Dnewt.debug=all`
and pipe all things to a file and attach here (which shall then contain your exception as well).

Meaning, let's fix the 'stencil' exception thing first.
Later we can indulge ourselves with "first off" (fixed functionality left-over stencil buffer)
and "alpha discard" (alternative to stencil shader pass).

gouessej wrote

Sven, why does the implementation URL still use http instead of https?

Err .. oversight or just sticky, knowing we forward http requests to our https.

Is it actually used in some automated way to download stuff
or just informal (as I assumed)?

I tried to update to the latest.  there is no maven repo for jogamp-fat, any version.

iirc fat was used so that a script could extract and repackage the natives, which made life much easier for my app users (and thus many times easier for me).

the test_dbg.zip provided earlier is run from the jogamp-all-platforms downloaded off the website, it is the LTS version.
Now when I build and run JoglVersion.getInstance().toString() says
 
-----------------------------------------------------------------------------------------------------
Package: com.jogamp
Extension Name: com.jogamp
Specification Title: JogAmp Java Bindings Specification
Specification Vendor: JogAmp Community
Specification Version: 2.4
Implementation Title: JogAmp Java Bindings Fat Jar
Implementation Vendor: JogAmp Community
Implementation Vendor ID: com.jogamp
Implementation URL: http://jogamp.org/
Implementation Version: 2.4.0
Implementation Build: 2.4-b952-20230201
Implementation Branch: origin/master
Implementation Commit: 9dce06050a8a607b8c4ab83bd3aba8460d9ca593
Implementation SHA Sources: null
Implementation SHA Classes: null
Implementation SHA Classes-this: null
Implementation SHA Natives: null
Implementation SHA Natives-this: null
-----------------------------------------------------------------------------------------------------

is this in the right direction?

I assume that you have already read this:
https://jogamp.org/wiki/index.php?title=Maven

You can find the fat JAR of the version 2.4.0 here:
https://jogamp.org/deployment/v2.4.0/fat/

What can make your life easier? There are some information about the packaging in our wiki:
https://jogamp.org/wiki/index.php?title=Foreign_Packaging
https://jogamp.org/wiki/index.php/JogAmp_JAR_File_Handling#Fat-Jar
You can use either the fat JAR not coming from the Maven repository or use several JARs with many build tools including Maven, Gradle and Ant to produce a fat JAR.

I had not.  I don't find the wiki intuitive.  Probably just me.  Like... I can't find anywhere that says what to put after "requires" in module-info.java.  I can't find the basic stuff, so if you have to assume anything assume I'm bad at searching.

I've managed to switch to the official maven releases (2.3.1) and cleaned out any reference to jogamp-fat that I could find.  I think everything is still building fine.

Now that's over... can someone tell me the right way to do these outlines? :)

Hi 'John',

as mentioned above, let's tackle the exception of yours so
we can see whether we have something to fix in JOGL allowing you to use
these buffers for your specific code.

(while doing this, I am mostly interesting to see whether we have a potential JOGL bug here)

imakerobots wrote

Currently I am using the jogamp-fat 2.4.0.  I think this was done so that the natives could be repacked for distribution correctly?  It's been a long time.  In practical terms it means that I can't access a bunch of internal texture formats like GL_STENCIL_INDEX8 or GL_DEPTH24_STENCIL8 because

> Caught GLException: format 0x8d48 not supported [yet], pls notify the maintainer in case this is our bug.

as mentioned, please attach the full piped stderr and stdout piped to a file here,
which also should include the mentioned stack trace.

perhaps add another one with mentioned debug flags.

Also: Please use the latest v2.5.0 RC using either our maven repo
or plain jar files. While I don't assume anything, I require you
to be capable to utilize these sources for me to be able to assist you.

Release Candidate
- https://jogamp.org/deployment/v2.5.0-rc-20230523/
  - Maven v2.5.0-rc-20230523 @ https://www.jogamp.org/deployment/maven/

Also see: https://jogamp.org/cgit/jogl-demos.git/tree/maven/trivial-test/README.txt
and: https://jogamp.org/wiki/index.php?title=Maven#The_jogamp.org_test_repository
(edited)

and perhaps see for updated RC versions: https://forum.jogamp.org/Release-2-5-0-td4042507.html

Thank you.

+++

Sorry, there is no 'quick fix service' for your problem w/o
finding time to dive into your code and the methods in detail.

But after we have tackled the simple exception,
I might find time sometime to see to a specific 'outline solution'
as I also have some interest in it as hinted.

Alternatively, a generic (simple) filter method (gaussian, toon, edge-detect, etc)
might be used but your mileage may vary.
These were mentioned in the referenced articles as discussed above.

Who is this "john" you keep referring to in quotes?  Is that funny to you?  you looked at the github project so I know you know my name.

I'm not interested in helping you investigate a bug that - by your admission - is not actually in my way.  I have enough bugs of my own, thanks.

From my end if feels like you're making me jump through ever-more hoops and calling me strange names at the same time.

What did I do to you to get this treatment?

As an outside observer, I'd suggest adjusting your expectations as you are not entitled to anyone's attention for free. Julian and Sven have made it clear they are willing to help as long as you are using the latest release candidate, you seem unwilling to put the effort in to accomodate that request, I don't see any particular malice here, just a mismatch in expectations.

Just my $0.02.

Harvey

imakerobots wrote

I had not.  I don't find the wiki intuitive.  Probably just me.  Like... I can't find anywhere that says what to put after "requires" in module-info.java.  I can't find the basic stuff, so if you have to assume anything assume I'm bad at searching.

I admit that it's not just you, the modularization has added its layer of complications. You can use what I mentioned many times in the forum about "--add-opens" to determine what you have to add into module-info.java. Maybe it would be nice to put that somewhere in the wiki too.

imakerobots wrote

I've managed to switch to the official maven releases (2.3.1) and cleaned out any reference to jogamp-fat that I could find.  I think everything is still building fine.

You should use the latest release candidate (2.5.0 RC as Sven said) so that you don't suffer because of a bug already fixed in an available version and I updated the wiki so that you have the necessary information to update your pom file to use it, please look at the correct subsection, the version 2.3.1 was mentioned only as an example, rather use the version v2.5.0-rc-20230523:
https://jogamp.org/wiki/index.php?title=Maven#The_jogamp.org_test_repository

I'll try to clarify some aspects but I totally agree with Harvey. We do our best to help you, we are volunteers.

P.S: There was a real misunderstanding. The version 2.3.1 was mentioned only as an example to avoid editing the page each time we release a version. Maybe putting the section about the test repository first would avoid such confusion. I admit that there is some room to simplify the use of JogAmp but it takes time.

imakerobots wrote

Who is this "john" you keep referring to in quotes?  Is that funny to you?  you looked at the github project so I know you know my name.

As I already wrote above, I remember you somewhat but sadly not your (given) name.
So I am kindly (guess not) asking to help me to remember your name,
so I can write to the person - not the company.
Since you didn't give me your name, I still replied using 'John' as in 'John Doe'
for people w/o name. OK, that was a joke on my behalf.
And we know how bad Germans (me) are with jokes :)
Probably insulting the whole 'home team' and destroying earth.
(another joke not really funny, considering the current events of
sending weapons for peace, cough cough)

imakerobots wrote

I'm not interested in helping you investigate a bug that - by your admission - is not actually in my way.  I have enough bugs of my own, thanks.

From my end if feels like you're making me jump through ever-more hoops and calling me strange names at the same time.

That is the interesting thing here.
No, I don't know whether using stencil buffers will not help you at all.
I have not looked into your code yet, but I did read over the information you provided.
The latter is fascinating and I wrote about it.
Yes, I might be willing to dive into this subject when I have time,
but it won't be a generic thing AFAIK.

Now, apart from the task,
the stencil exception might be an issue of JOGL
and I like it to be resolved first - the low hanging fruit.
Perhaps it also allows you to use it after fixing it
and maybe it gives you also a good enough result for your own goals?
I don't know Sir.

imakerobots wrote

What did I do to you to get this treatment?

When you do a word count, you might realize that you are given
an excellent amount of attention.

I don't mean evil dude, I am not G**gle ;-)
But yes, maybe sometimes I am too annoying and please accept my apologies.
Hugs,

~Sven

Edit (PS): @Harvey: Thank you for helping trying to make peace.
@Julien: .. and you as well.

added repository following https://jogamp.org/wiki/index.php?title=Maven#The_jogamp.org_test_repository

Commit 971aba62 to branch https://github.com/MarginallyClever/Robot-Overlord-App/tree/new-outline (hello, people of the future!)

Running com/marginallyclever/robotoverlord/renderpanel/OpenGLTestStencil.java::main()...

2023-06-03-01.gif

Excuse me, a line got deleted.

After adding the test repo I upgraded to the 2.5.0-rc-20230523 edition.

Also to whom it may concern, "requires jogl.all" seems to have satisfied module-info.java

running from inside intellij with "-Dnativewindow.debug=all -Djogl.debug=all -Dnewt.debug=all" program arguments changes nothing.  there is no additional output.  but given my main() does nothing with args, I'm not surprised.