Graph Type Rendering Updates (Graph UI)

classic Classic list List threaded Threaded
69 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Re: Graph Type Rendering Updates (Graph UI)

Sven Gothel
Administrator
GraphUI – Easy to Use for your Desktop & Embedded Systems

Showcases the most simple UISceneDemo00 .. nothing more.
Reply | Threaded
Open this post in threaded view
|

Re: Graph Type Rendering Updates (Graph UI)

Sven Gothel
Administrator
.. and here it is GraphUI – Type Animation at your Fingertips

... text animation assembling one line of text, while each glyph coming from from a random 3D point moving to its destination – all at once.
Reply | Threaded
Open this post in threaded view
|

Re: Graph Type Rendering Updates (Graph UI)

gouessej
Administrator
Good work :) What's next?

Why do you plan to use Doygen?
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: Graph Type Rendering Updates (Graph UI)

Sven Gothel
Administrator
In reply to this post by Sven Gothel
Sven Gothel wrote
.. and here it is GraphUI – Type Animation at your Fingertips

... text animation assembling one line of text, while each glyph coming from from a random 3D point moving to its destination – all at once.
Each animated type's original quadratic shape is preserved, cached in its original em-size and then rendered on the GPU in perfect quality for each rendered frame using its current modelview matrix (rotation, scale and translation). This is unlike a traditional font API, where one creates static images at a certain resolution and size, then resizes and distort the pixel shape!
Reply | Threaded
Open this post in threaded view
|

Re: Graph Type Rendering Updates (Graph UI)

Sven Gothel
Administrator
In reply to this post by gouessej
gouessej wrote
Good work :) What's next?
Make the glyph handling perfect w/ kerning
and exposing such a GlyphString in GraphUI for easy use.
Already working on it.

Then of course a demo video on RaspiPi4 on bare-metal from console, but that's a given.

Then .. we have to see.

Why do you plan to use Doygen?
Because javadoc sucks big time.
They removed the 'frame' stuff and only provide 'search',
at least shown by my last attempt to use OpenJDK17 .. (Last one produced w/ OpenJDK11).

Also, Doxygen simplifies the 'tagging' (making links) and you can use markdown
instead of wasting time w/ html lists and paragraphs.
That is really time preserving while generating nice docs.


Reply | Threaded
Open this post in threaded view
|

Re: Graph Type Rendering Updates (Graph UI)

Sven Gothel
Administrator
In reply to this post by Sven Gothel
From demo to proper code ;-)

Well, fixed the PIA setTransform(..) and it is what it is,
always quite sensitive when using the matrix for everything including zoom.
Plain and stupid basic stuff, I know.

+++

The label (multiline text) needed to have origin 0/0 to work well w/
the build-in drag-zoom, all Shapes need.

OK, decoupled Shape from GraphShape, allowing non-graph stuff to be placed as well.
This also simplifies review, since Shape only contains the usual stuff (simple scenegraph if you must call it)
- lifecycle and locking/sync
- matrix ops

GraphShape details the Graph GLRegion handling.

Hence we can have a container of shapes in this regard, yes
- see it as a scenegraph node w/ build-in transformation node :)

Still, trying to keep it simple (KISS).

++++

All of the above was 'triggered' by the need to have a transformable container,
maybe having Graph Glyph's from a text to do something (type animation).
Now it can be used for anything.

So besides wasting my time with acquisition and paperwork,
I shall complete this container as well, then test on Raspi again.
Sort of a first finishing line.

Reply | Threaded
Open this post in threaded view
|

Re: Graph Type Rendering Updates (Graph UI)

Sven Gothel
Administrator
UISceneDemo03 update using the new GraphUI GlyphShape, handling string processing into a list of GlyphShapes while preserving unscaled target position inclusive kerning. The demo also uses an enhanced smooth target arrival.

https://jausoft.com/blog/2023/03/29/graphui-type-animation-update-1/
Reply | Threaded
Open this post in threaded view
|

Re: Graph Type Rendering Updates (Graph UI)

gouessej
Administrator
In reply to this post by Sven Gothel
I knew that you would end up by creating a scenegraph API ;)
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: Graph Type Rendering Updates (Graph UI)

Sven Gothel
Administrator
Wait for the contourless Container and its Group implementations
traversing through the tree with the PMVMatrix .. yeah,
it is what it is .. but still KISS and efficient ;-)

In a way a good minimalistic experience
to be ready for perhaps other migrations (OpenJFX maybe if ...).

We will see.

Reply | Threaded
Open this post in threaded view
|

Re: Graph Type Rendering Updates (Graph UI)

gouessej
Administrator
As long as it's modular, it won't look like Google Guava.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: Graph Type Rendering Updates (Graph UI)

Sven Gothel
Administrator
Unaware of that Guava .., whatever, the Graph and GraphUI separation stays intact.

OK, I did an old long outstanding job: Completing Metrix4f w/ Vec[234]f
to clarify the math code (for now mostly used within GraphUI).

Now we can get rid, step by step and if useful, of exposing the ugly 'float[]' vectors and matrices ;-)
Will see whether it makes sense to change PMVMatrix, due to the memory transfers,
but that's not so important as the API wraps around that.

Unit tests w/ performance checks added as well of course.

+++

Well, the GraphUI Group has been added as well and implementing a Container w/ Scene.
Hierarchy w/ traversing the PMVMatrix using simple visitors works fine.

So far so and so ;-)


Reply | Threaded
Open this post in threaded view
|

Re: Graph Type Rendering Updates (Graph UI)

Sven Gothel
Administrator
General invert hack using scaling w/ 1f/determinante gives +10%,
I would have thought this would have been optimized these days already on OpenJDK 17+

Additional Matrix4f perf improvement over FloatUtils
- invert (..) +14% faster for aarch64, 2% amd64
- mul(..) +14% faster for aarch64, 10% amd64

.. sure, these are all synthetic and only used for 'per object' affine stuff
like PMV matrix calculus when traversing through the world (picking, draw preparation ..).

But it was interesting to see where we are.

Now since this also at least demonstrates the 'new' code works and is not slower,
while exposing a nice OO math API - I probably will see how to replace FloatUtil in PMVMatrix
as well.

2nd edit:
- 1st math commit 15e60161787224e85172685f74dc0ac195969b51
- update commit (this post) 10b60e10ece3cbc3e0b8a68ac73229371530e0ba
Reply | Threaded
Open this post in threaded view
|

Re: Graph Type Rendering Updates (Graph UI)

Sven Gothel
Administrator
.. realizing I probably should have dropped this in a separate discussion thread ;-)

Almost through the rewriting of PMVMatrix for 1st draft, surely its the usage and test cases
to adopt causing the work (PIA) lol.

Impact will be
- potential slightly faster user matrix ops 10%+

- better to read and maintained code

- GLUniformData will call a SyncAction of the data provider (PMVMatrix)
  to store the 16 floats in .. you guessed it, float array ;-)
  So this part closes the loop-hole to use the matrices w/ glUniform*()

While doing this top to bottom cleanup, a few ugly temporary vars also got dropped,
which is generally a good sign as well.

Reply | Threaded
Open this post in threaded view
|

Re: Graph Type Rendering Updates (Graph UI)

Sven Gothel
Administrator
Big Easter cleanup completing the Matrix4f, Vec* etc w/ PMVMatrix rewrite.

Big Easter Cleanup
- Net -214 lines of code, despite new classes.
- GLUniformData buffer can be synced w/ underlying data via SyncAction/SyncBuffer, e.g. SyncMatrix4f + SyncMatrices4f
- PMVMatrix rewrite using Matrix4f and providing SyncMatrix4f/Matrices4f to sync w/ GLUniformData
- Additional SyncMatrix4f16 + SyncMatrices4f16 covering Matrix4f sync w/ GLUniformData w/o PMVMatrix
- Utilize Vec3f, Recti, .. throughout API (Matrix4f, AABBox, .. Graph*)
- Moved FloatUtil -> Matrix4f, kept a few basic matrix ops for ProjectFloat
- Most, if not all, float[] and int[] should have been moved to proper classes
- int[] -> Recti for viewport rectangle
- Matrix4f and PMVMatrix is covered by math unit tests (as was FloatUtil before) -> save

Passed all unit tests on AMD64 GNU/Linux
.. now back to some productive / art stuff ..
Reply | Threaded
Open this post in threaded view
|

Re: Graph Type Rendering Updates (Graph UI)

gouessej
Administrator
In reply to this post by Sven Gothel
Why does the invert hack help?
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: Graph Type Rendering Updates (Graph UI)

Sven Gothel
Administrator
(a) mul is faster than div ..
(b) w/ hotspot it might be better to separate some functional stuff into a funtion to make it a better suitable candidate for jit
Reply | Threaded
Open this post in threaded view
|

Re: Graph Type Rendering Updates (Graph UI)

gouessej
Administrator
Thank you for the explanation. Actually, we already do the same in ardor3d-math:
https://jogamp.org/cgit/ardor3d.git/tree/ardor3d-math/src/main/java/com/ardor3d/math/Matrix4.java#n1822
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: Graph Type Rendering Updates (Graph UI)

Sven Gothel
Administrator
Thank you .. will compare them a bit more.

If I could find a streamlining (non-branch) max() and abs() function,
it would help to make it more simd alike.

abs(): But Java's float<->int bits is a native methods and kills performance,
so no pure java bitpattern for sign. Using the Math.abs() b/c it might have an intrinsic.

Math.max() is much slower, so no intrinsic and hardcoded.

...

Re mul:
Besides we are using floats, I also tuned the number of temporaries.
In Matrix4f we have a less, as in less is a bit faster.
Its sort of useless witch hunting, I know - the optimization of the build-in is far less fancy than for gcc or llvm these days.
But .. its OK'sh.

Re invert
Ardor doesn't scale the input by 1/max, hence there could be an overflow?
Yeah, also a double thing perhaps :)

Avoiding double precision .. maybe no issue these days on big CPUs .. but embedded is still a thing for me.

...

Whatever, most important was that I didn't inject a performance regression, we are faster than before - so all good.
Reply | Threaded
Open this post in threaded view
|

Re: Graph Type Rendering Updates (Graph UI)

Sven Gothel
Administrator
GraphUI – Type Animation Update 2
https://jausoft.com/blog/2023/04/10/graphui-type-animation-update-2/

- Fixed interaction issue on rotated Shapes
- Rotate Group (Container) w/ animated Glyphs for fun ..
Reply | Threaded
Open this post in threaded view
|

Re: Graph Type Rendering Updates (Graph UI)

Sven Gothel
Administrator
I have made Group properly be able use Group.Layout (GridLayout + Padding),
also used by the convoluted UISceneDemo20.

This demonstrates GraphUI's capability to be used with correct layout,
i.e. its pure matrix based position, scale and rotation.

See full commit

+++

Now I think about next demos and user features:
- General FFMpeg encoder, allowing to screencap demos etc,
  or even produce a full fledged media editor
  or audio/video chat application

- Extracting subtitles from media stream (GLMediaPlayer)
  and displaying them with GraphUI (MediaButton and Glyphs),
  perhaps even animating them into the picture...

I like both .. but what would you like (first)?
1234