| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
and w/ scroll-wheel (or zoom if alt is pressed)
|
|
|
|
| |
them no more interacting when arrived. Play: Drag 'em ;-)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
invPMv null; PMVMatrix: Make Mvi, Mvit optional at ctor, add user PMv and PMvi - used at gluUnProject() ..
Matrix4f.mapWin*() variants w/ invPMv don't need temp matrices,
they also shall handle null invPMv -> return false to streamline usage w/ PMVMatrix if inversion failed.
PMVMatrix adds user space common premultiplies Pmv and Pmvi on demand like Frustum.
These are commonly required for e.g. gluUnProject(..)/mapWinToObj(..)
and might benefit from caching if stack is maintained and no modification occured.
PMVMatrix now has the shader related Mvi and Mvit optional at construction(!), so its backing buffers.
This reduces footprint for other use cases.
The 2nd temp matrix is also on-demand, to reduce footprint for certain use cases.
Removed public access to temporary storage.
+++
While these additional matrices are on demand and/or at request @ ctor,
general memory footprint is reduced per default and hence deemed acceptable
while still having PMVMatrix acting as a core flexible matrix provider.
|
| |
|
|
|
|
|
|
| |
as well as getSurfaceSize(..) (use absolute size)
Tested w/ UISceneDemo01b and UISceneDemo03, where you now can pick any moving glyph at any rotation and drag it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Utilize Vec3f, Recti, .. throughout API (Matrix4f, AABBox, .. Graph*)
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
traversing the PMVMatrix throughout childs (-> see TreeTool).
Utilizing the Vec*f (and Matrix4f) API w/ AABBox et al renders our code more clean & safe,
see commit 15e60161787224e85172685f74dc0ac195969b51.
A Group allows to contain multiple Shapes,
hence the PMVMatrix must be traversed accordingly using TreeTool
for all operations (draw, picking, win->obj coordinates, ..).
Hence Scene + Group are now implementing Container
and reuse code via TreeTool and a Shape.Visitor*.
This will allow further simplification of user code.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ray, AABBox, Frustum, Stereo*, ... adding hook to PMVMatrix
Motivation was to simplify matrix + vector math usage, ease review and avoid usage bugs.
Matrix4f implementation uses dedicated float fields instead of an array.
Performance didn't increase much,
as JVM >= 11(?) has some optimizations to drop the array bounds check.
AMD64 + OpenJDK17
- Matrix4f.mul(a, b) got a roughly ~10% enhancement over FloatUtil.multMatrix(a, b, dest)
- Matrix4f.mul(b) roughly ~3% slower than FloatUtil.multMatrix(a, b, dest)
- FloatUtil.multMatrix(a, a_off, b, b_off, dest) is considerable slower than all
- Matrix4f.invert(..) roughly ~3% slower than FloatUtil.invertMatrix(..)
RaspberryPi 4b aarch64 + OpenJDK17
- Matrix4f.mul(a, b) got a roughly ~10% enhancement over FloatUtil.multMatrix(a, b, dest)
- Matrix4f.mul(b) roughly ~20% slower than FloatUtil.multMatrix(a, b)
- FloatUtil.multMatrix(a, a_off, b, b_off, dest) is considerable slower than all
- Matrix4f.invert(..) roughly ~4% slower than FloatUtil.invertMatrix(..)
Conclusion
- Matrix4f.mul(b) needs to be revised (esp for aarch64)
- Matrix4f.invert(..) should also not be slower ..
|
|
|
|
|
|
| |
GL/VK abstraction at a later time differently
Actual GPU rendering toolkit dependency can be abstracted differently, i.e. GPU <- { GL, VK } etc.
|
|
|
|
| |
fractional to box size) and Scene for all Shapes.
|
| |
|
| |
|
|
|
|
| |
screenshots, add launch screen (visible @ '-wait')
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use w/ UISceneDemo03 Type Animation...
A list of GlyphShape can be created via GlyphShape.processString(..),
which preserves all details incl. intended original unscaled position and its kerning.
Whitespace or contourless Glyphs are dropped.
A GlyphShape is represented in font em-size [0..1] unscaled.
+++
UISceneDemo03 Type Animation
- Using GlyphShape and apply scaling via its Shape.setScale()
- Recalc fontScale per used text
- Refined 'arrival' criteria and smoothing out near target w/ speed-up rotation
- Using GraphUIDemoArgs to parse common commandline demo options
|
|
|
|
| |
using Glyph bounds minY()
|
| |
|
|
|
|
| |
Graph/GLRegion
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
used in our window dtor event handler)
|
|
|
|
| |
OutlineShape.Visitor, allowing to use the Glyph (information).
|
| |
|
|
|
|
| |
setPlanBox(..)'s gluUnProject(..)
|
|
|
|
| |
launcher to our new UISceneDemo naming series
|
| |
|
|
|
|
| |
showing current surfaceSize
|
|
|
|
| |
GLAutoDrawable.invoke(..) API doc: Add semantics about GLRunnable return value.
|
|
|
|
|
|
|
| |
its default. GraphUI: Always use default.
Graph RegionRenderer, its RenderState as well as GraphUI's Scene don't need to have knowledge of Vertex.Factory,
which is only used within OutlineShape and its 'inner geom workings'.
|
|
|
|
| |
destroyImpl()
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Contrary to UISceneDemo0[01], here we
- Call the Scene GLEventListener methods manually
- Issue glClear* ourselves
- Using own PMVMatrixSetup
- gluPerspective like Scene's default
- no normal scale to 1, keep distance to near plane for rotation effects. We scale Shapes
- translate origin to bottom-left
- Scale Button not by screen-size but Scene.getBounds() dimension,
hence issue setupUI() from reshape() and not from init()
- GLButton: Using additional view-rotation like UISceneDemo01
- Multi-line text labels resize issues are
- Supposed sticky-edge is moving
(Sticky-edge are the opposites of the picked drag point)
|
|
|
|
| |
toggled off
|
| |
|
|
|
|
| |
an own Scene.PMVMatrixSetup with a plane dimension of 100
|
|
|
|
| |
normalized plane dimensions, 1 for the greater of width and height
|
| |
|
| |
|
|
|
|
| |
UISceneDemo01 simply provides shape drag-move and -resize
|
|
|
|
| |
or null on error instead of boolean to easy API usage
|
|
|
|
| |
stop animator
|
|
|
|
| |
showing simple linear Shape movement w/ listener attached
|
|
|
|
| |
clean)
|
| |
|
|
|
|
| |
00dbacc5af3531af50e77a02d534dc11e08de10f, 913b00f8b876e29af91677ef61b3eb35d6853e6e
|
|
|
|
| |
and destroys it. Dropping this also from user (complexity).
|
|
|
|
| |
from transition to use TextureSequenceES2
|
|
|
|
|
|
|
|
| |
using a local instance, enable performing on any thread (not using a blocking GL renderer thread)
Shape got 2 win<->obj and size-retrieval variants:
(a) using given PMVMatrix and viewport
(b) using a local PMVMatrix w/ Scene's viewport and using Scene's setupMatrix()
|