Hi there,
I agree with Mr. Tugai. I have similar problems implementing a research
project. I think we speak about different issues. Big model with
standing geometry and only one TransformGroup will work well. The memory
leak occurs, if you change the geometry as well as transformations
during runt
Hi All,
I would like to create an application that will create control rooms
with hundreds of racks(with crates inside). This racks, their geometry
and position, are stored in a database. I would like to create an object
Rack with the 3DS and store it in a format(suggestions??) so that
afterwards I
When a BranchGroup is detached, Java 3D will not let go of the memory
retained by that BranchGroup. The workaround, and a pretty dumb one at that,
I've devised is to simply attach and detach a dummy BranchGroup to flush
out the retained memory. And this has been acknowledged by Kelvin Chung as
an e
To make that clear:
the method you described helps to free memory at the detached
BranchGroups formely parent?
N. Vaidya schrieb:
> When a BranchGroup is detached, Java 3D will not let go
> of the memory
> retained by that BranchGroup. The workaround, and a
> pretty dumb one at that,
> I've devis
Hmmm...I think it is something like this.
Suppose I've a live BranchGroup which is the parent of a subgraph containing
possibly other Groups and, in particular, Shape3D's with possibly many
Appearances and Geometries. If I detach this BranchGroup then my experience
has been that the memory corresp
...sounds interesting. I will try it, to get the memory back. Do you
know something about the TransformGroup problem? I have created a basic
class called Object3D sub-classed from TransformGroup. Inside a two
dimensional view, the user can move a point (or more...), by dragging.
The 3D shape of thi
Have you tried invoking the GC ? - repeatedly and successively ? Though the
GC has a mind of its own, I've found that it usually responds if you coax it
well enough :).
And about the e-mail link, and based on its findings with the profiler, I
can only surmise that there is either a genuine memory
Eike,
Just to add to my previous e-mail
I did read that you're not creating any new objects. But mentioned the GC
because getting and setting the Transform3D probably creates copies. But I
wonder if that would lead to a 20MB memory leak since you seem to be doing
the updates manually.
Vaidy
Yes, I've tried to call the GC manually - with no result.
I've stopped at the moment the Java3D part, because the memory usage is
too high. Probably I can improve the code, but I will have in the final
model something like 5000 objects. JOGL has a footprint with same
objects of 25MB instead of 70MB
Eike,
Without seeing your program, here is my guess to the problem
you having.
In general, Java 3D operates via message passing.Imagine
you have a user thread, that isn't bounded by the j3d frame
rate, transmitting TG change requests to j3d. It is very likely that
the user thread is
Eike,
If you are updating the scene faster than the frame rate,
calling GC mamually will not help. The reason is that j3d has a
memory manager for recycling objects to minmize GC, but this
manager is a little too greedy. Here is the bug report, and it
apply to all scene update operations :
Chien,
Eike's updates are made by user gesture. Wonder if he could be doing that
continuously at a rate faster than the FPS to produce a ~20MB leak. The
diagnosis for the problem mentioned in his e-mail link does seem to be correct.
Agreed a testcase would help !
Regards
Vaidya
>On Wed, 14 Ap
Also when these updates are triggered external - why could it be useful to
handle more "gestures" than can be displayed? If these data aren't used
anywhere else this sounds a little bit like wasting computing power. And
in case they are used elsewhere wouldn't it be possible to compute all
data but
Good point ! you're thinking of something like a queue where messages get
stacked and only the latest one is grabbed between frame updates and then
the queue is cleared up ? My guess - just a plain guess - as to why such a
thing hasn't been conceived is probably because separate queues don't exist
>Just to give you an idea about the dimensions:
>My biggest scene uses more than 500 Shape3Ds, every with at least one
>BranchGroup and one TransformGroup (and of course some are textured).
>With some additional Groups which organize the data that makes much
>more than 1500 elements directly within
Exactly. Every thing else sounds like a program design problem. This queue
also would allow it to send all data to the (fictious?) other receiver of
the data and only the necessary amount to J3D.
On Wed, 14 Apr 2004 13:51:07 -0600, N. Vaidya <[EMAIL PROTECTED]> wrote:
Good point ! you're thinking
From: N. Vaidya
Sent: Wednesday, April, 14th, 2004 20:47
Dear all,
> [Memory leakage in J3D]
As I have just spent two bitter weeks searching for and trying to
identify this issue a little better, I might be of a little help,
there.
My application's requirements are that I have a relatively
Dear all,
as I already mentioned in the other post regarding getting rid of the
memory leakage, I have a problem with picking in my application:
Whatever I do, it doesn't come out right and the PickResults don't
seem to differ much, whether I use
.getNode(PickResult.TRANSFORM_GROUP) or ...(GROUP)
Hi,
how to identify the facet selected by the user by clicking on the canvas?
thanking you
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA3D-INTEREST". For general he
Yes, this is called message compaction and j3d did use this technique
for the case of TG update.
But doing this inside j3d will not totally eliminate the problem as
j3d's threads are bounded
by the frame rate., esp. when the TG message rate >> the frame rate.
- Chien Yang
Java 3D, Sun Microsystems
20 matches
Mail list logo
