Yeah I agree! (please read the following with a sarcastic tone) ... may be, like a lot of newbies writing "bitch e-mails", I figured that Java & Java3D would be as it is supposed to be (or at least how Sun sells the idea) a "high level language" in which the programmer does not has to worry about the platform implementations and/or hardware implementation ... I apologize for eating the so good looking and tasty hook of "platform/hardware independency" :P ... if in the required time to develop a project I have to learn what Java/Java3D is supposed to hide to the developers, and therefore delay the end of the project I better apply that time to learning a lower level technology (which I would have to learn any way with the Java/Java3D surprises) and stop paying the performance slow down for using a virtual machine ;)
-----Original Message----- From: Discussion list for Java 3D API [mailto:[EMAIL PROTECTED] On Behalf Of Justin Couch Sent: Thursday, February 27, 2003 1:55 PM To: [EMAIL PROTECTED] Subject: Re: [JAVA3D] Out of memory with textures Risto Rangel-Kuoppa wrote: > Thx for the reply. I also thought in using the updating tools but since > I am someway new to Java3D I choose the path of coding them, since after > all it should work in either way. But I was able to achieve my needs > with the "reference keeping" approach. Also, I choose to code it since > the changes in the textures is almost a pixel based and dependent on > others pixels content -somekind of a pixel shader. Thanx :) <rant> Unfortunately these are the sorts of things that we end up having to deal with over here in the J3D community, which are far, far less prevalent in other 3D graphics API communities. A lot of newbie programmers assuming that just because it's the easiest way of doing things that Java3D should just magically do things correctly. Then, some time later a bitch email comes through that says "java3d suxs - it uses so much memory!". Texturing is just one of them - the other one is the geometry/transform group stuff. Just because you can, doesn't make it the best way of doing things. In J3D it is exacerbated by the programmers not bothering to try to understand fundamental 3D graphics concepts, so trying to convince them of the errors of their ways is even harder than normal. </rant> Even if you are changing the entire image, it is far, far more efficient to use the setSubImage() API calls than to replace the entire texture. At the hardware level, there is a lot of setup issues required to create new textures. Once that texture is created, replacing parts of it (where the part could be the entire contents) is extremely cheap in comparison. If you are doing a pixel-shader-like function, then this will make a significant performance difference. -- Justin Couch http://www.vlc.com.au/~justin/ Java Architect & Bit Twiddler http://www.yumetech.com/ Author, Java 3D FAQ Maintainer http://www.j3d.org/ ------------------------------------------------------------------- "Humanism is dead. Animals think, feel; so do machines now. Neither man nor woman is the measure of all things. Every organism processes data according to its domain, its environment; you, with all your brains, would be useless in a mouse's universe..." - Greg Bear, Slant ------------------------------------------------------------------- ======================================================================== === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA3D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA3D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
