Is there a way to implement a TransformGroup such that the points will be differently transformed depending on their position?
That leads that on OpenGL I have to call the appropriate glTranslte*, glRotate*, glScale* before each point.
Thank you for your explanantion they were really usefull. And what you are sayinmg makes sense :).
Is it possible with API JOGL provides to use parts of the gfx pipline for vec math, or has this to be implemented by yourself using JNI and for example OpenGL.
Due to that Java3d is built on top of OpenGL or DirectX would it be possible to write the vecmath API that it uses the VPU. Or are there such librarys for vecmath that use the VPU.
And when using such a library (if exists) is there no performnace lost in the 3D rendering due to the parralle usage of the VPU for vec math of your own and the one performed during the rendering process?
The problem here is it doesn't make sense to write a "vanilla" math library
to use the hardware, as JNI incurs a performance hit for every call. Where
it makes more sense is to port entire algorithms to work on large data sets
via nio calls. Here, you're on your own as they'd be your own algorithms
and your own data sets. You have to be well versed in the technology too,
its no use simply using a technology because it has the potential to go
faster. Bottom line is its a lot of work without much benefit, made worse
by the fact there will be vertex shaders available in j3d to do all that
kind of work for you "real soon." You may also find that the vecmath
calculations are "fast enough." Tweaking performance is usually the last
step in 3d app development. You can't forget about it entirely, but unless
you have a clear idea of where in the pipeline you've situated the
rendering bottleneck (every 3d app has one), its generally a waste of
effort to worry about code that doesn't affect the bottleneck.
At 01:58 AM 11/12/2004, you wrote:
>Thank you for your explanantion they were really usefull. And what you are
>sayinmg makes sense :).
>Is it possible with API JOGL provides to use parts of the gfx pipline for
>vec math, or has this to be implemented by yourself using JNI and for
>Due to that Java3d is built on top of OpenGL or DirectX would it be
>possible to write the vecmath API that it uses the VPU. Or are there such
>librarys for vecmath that use the VPU.
>And when using such a library (if exists) is there no performnace lost in
>the 3D rendering due to the parralle usage of the VPU for vec math of your
>own and the one performed during the rendering process?
>[Message sent by forum member 'nitro' (nitro)]
>To unsubscribe, e-mail: email@example.com
>For additional commands, e-mail: firstname.lastname@example.org
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
The overhead of doing transform calculations on hardware is expensive, so having to do it on a per-vertex basis is a performance nightmare.
Yes, but not till 1.4
With the recent advent of programmable vertex shaders, you can do this kind of thing much more quickly in hardware than in hardware from 2 years back via a shader.
You can get that effect, but not they way described. If you don't complie your scene and, and all your geometry is passed by index and reference, you can apply whatever transforms you want to whatever vertices you want whenever you want via a parallel transform heirarchy--but j3d won't do any of this automagically for you, and you will still take the usual performance hits for each transform calculation.
--To Dusty: yes. I have got a geoemetry(one for example a truss) which can be twisted, stretched, torsioned and if you wont be able to scale the the amount of twisting, stretching and torsion. In short non affine transformations on an object.
--to bayblade: About the longest answer. What do you mean with "via parallel transform"? Its just recalculating the points am I right. But wouldn't this be faster if done via the graphics hardware (As a I said by translating rotating each point)? From your answer I hear out that coded transformations are faster then transfromations on the graphics hardware. Are you sure of this?
>to bayblade: About the longest answer. What do you mean with "via parallel
Remember, transforms are typically accommodated by a heirarchy, so if you
transform a parent node (a TransformGroup does this in j3d), the child
transforms with it. The hardware paradigm typically works something like
pushing the transform onto the appropriate matrix stack, where it gets
multiplied with its parent and then adding all child nodes (and their
respective vertices, which in turn are multiplied by the top of the matrix
stack) before poping the transform matrix back off the stack. While most
VPU hardware will do these multiplications more quickly than most CPU
hardware, its till a very expensive operation.
If you push and pop a matrix for every vertex or even every face, you'll
see your frames bottom out in no time. Now this isn't true for all cases,
but for most cases it makes more sense to cut back on the number of
transforms fed to the gfx pipeline, than it is to feed the same number of
transforms to faster hardware. The hierarchy as it stands doesn't do
sub-object (i.e. per-vertex) transforms, so to do this you'll need to set
up your own transform hierarchy (based on your vertex hierarchy) and "move"
the vertices on your own, as needed. This is the parallel hierarchy I meant.
For better performance, you can still leverage a VPU to do your matrix math
via MMX, SSE, Altivec, your GPU (using jogl is nice, as it will set up a
parallel stacks for you to push and pop), or some other "fast" JNI vector
library, its just significantly more effort, and there is still a
performance hit as the sub object transforms occur earlier in the pipeline
and will still incur some overhead (at the application level) while the
rest of the transforms will still occur later on.
Sorry I don't understand everything. First what stands GPU, SSE, Altivec, VPU for.
What dou mean by "using JOGL is nice". If I use JOGL I would use the gfx pipline for my transfromations, and that is what I should not do if I understand you right.
Why has it to be a JNI vector library. As far as I know are basic operations (multiply add ...) in Java as fast as in any native language.
At 12:59 PM 11/11/2004, you wrote:
>Sorry I don't understand everything. First what stands GPU, SSE, Altivec,
GPU is a Graphics Processor, which is a specific type of VPU--a Vector
The idea here is you can use SIMD (single instruction, multiple data)
technologies like MMX, SSE, or Alitvec to do vector processing on a CPU
(different technologies for different CPUs) or a dedicated Vector unit
(like your graphics chip) to do your vector (matrix) math. The math IS
simple (adding and multiplying), but there's alot of it going on and a
vector unit will do much or all of it in parallel. For non-vector
calculations, Java is certainly in the same ballpark of performance as
other languages when crunching numbers, but neither Java nor other
languages are as fast when it comes to doing heavy matrix arithmetic as a
dedicated vector processor.
>What dou mean by "using JOGL is nice". If I use JOGL I would use the gfx
>pipline for my transfromations, and that is what I should not do if I
>understand you right.
Kinda. OpenGL is certainly intended as a graphics API, but since matrix
math is tied into graphics so heavily, it performs a number of matrix
operations as well, (though most are done implicitly, so you need to know
where to look) which should run at higher speeds than your CPU (this will
depend on your OpenGL driver, underlying hardware and how well you know
OpenGL). You don't have to actually push data through the whole pipeline,
just move some data inside it, perform the right operations on it and
retrieve what comes out. If what I'm saying here still doesn't make much
sense, its probably going to be more trouble than its worth, so don't worry
>Why has it to be a JNI vector library. As far as I know are basic
>operations (multiply add ...) in Java as fast as in any native language.
It doesn't at all. Sorry I'm not being clear. Indeed, the vecmath library
in j3d is "pure" Java, very easy to use and gives decently accurate output,
but its not even close to the speed of a high-end vector unit. That's
all. if you discover your performance lags significantly after adding the
additional transformation code, you may want to look at moving the
transform math from the JVM to some under-used piece of hardware that can
do it more quickly.
Nothing I've described here is trivial either. It CAN be done, but its
alot of difficult work, hence the short answer was no.
Thank you for your explanantion they were really usefull. And what you are sayinmg makes sense.
Is it possible with the API JOGL to use parts of the gfx pipline for vec math, or has this to be implemented by yourself using JNI and for example OpenGL.
Due to that Java3d is built on top of OpenGL or DirectX would it be possible to write the vecmath API that it uses the VPU.
Is there a reason not to design the scenegraph such that the points that need to be differently transformed are in separate TransformGroups under the main TransformGroup?
Your use of this web site or any of its content or software indicates your agreement to be bound by these Terms of Participation.
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.