Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (541)
Games in Android Showcase (133)
games submitted by our members
Games in WIP (604)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Should I use Java3D in my aplication?  (Read 1229 times)
0 Members and 1 Guest are viewing this topic.
Offline uderman

Senior Newbie




Java games rock!


« Posted 2004-06-20 21:09:03 »

hello,

I need to build a networked virtual environment, and need to create the 3d space, and some 3d objects to play around. I asked at the JOGl forum if using JOGl was my best choice, and they said that I should use Java3D or Xith3D:

http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=jogl;action=display;num=1087577051

As far as I know, I would get best performace using Opengl, and would get the project better organized and would deal with the 3D objects in a network better using Java3D or Xith3D. Am I correct?

Also, I would like to know if Java3D really is slow, takes more space, more memory and stuff, is it true?

Is it possible to use Java3D in my aplication? Couse a important part of the project is study he behaves of the virtual environments when more users connect to it. Would it be a issue when sending packages over the network with informations about the objects(like position, moviments, if it´s selected by other users and more)?

Thanks for ya help.

uderman
Offline Herkules

Senior Devvie




Friendly fire isn't friendly!


« Reply #1 - Posted 2004-06-21 05:51:05 »

Quote
As far as I know, I would get best performace using Opengl, and would get the project better organized and would deal with the 3D objects in a network better using Java3D or Xith3D. Am I correct?


No. The high-level system are built to keep performance high in complex environments. For simple environments, you will be faster with low-level APIs like JOGL, but the higher the structures get, the more you'll start to reinvent Xith/Java3D.
Maybe your scenestructure doesn't match a scenegraph; in this case, yes, start with JOGL and build your own high-level stuff.

Quote

Also, I would like to know if Java3D really is slow, takes more space, more memory and stuff, is it true?


Depends. Mostly yes. For a VR-type of application you might draw benefit from Java3Ds asynchronous behaviour system. A thing that Xith doesn't have. Or if you wanna run in a CAVE.... that's what Java3D was made for.

Quote

Is it possible to use Java3D in my aplication? Couse a important part of the project is study he behaves of the virtual environments when more users connect to it. Would it be a issue when sending packages over the network with informations about the objects(like position, moviments, if it´s selected by other users and more)?


This is more a networking question and doesn't depend so much on the rendering API.

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline Mithrandir

Senior Devvie




Cut from being on the bleeding edge too long


« Reply #2 - Posted 2004-06-26 16:18:03 »

Quote
Depends. Mostly yes. For a VR-type of application you might draw benefit from Java3Ds asynchronous behaviour system. A thing that Xith doesn't have. Or if you wanna run in a CAVE.... that's what Java3D was made for.


As I do this sort of work for a living, I'm going to have to register a strong disagreement here. Asynchronous changes to a scene graph really don't help writing a large scale application at all. In reality, what happens is that it causes a lot of horrible rendering artifacts. For example, getting two transforms updated at different times in the tree leads to odd movement (jitter) of objects. Every real world Java3D app ends up synchronising every access to the scene graph through a single WakeupOnElapsedFrames() behaviour.  Perhaps they'll also use the AWT event behaviour too, but all the others are ignored. They're great for very simple apps, but for anything robust, they don't cut it.  In that respect, Xith3D, Java3D, Aviatrix3D and all the other scene graph APIs end up doing and looking like exactly the same thing.

The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline bmyers

Junior Devvie





« Reply #3 - Posted 2004-06-26 16:57:36 »

Hmmm...

I am using multiple asynchronous WakeupOnElapsedFramesBehaviors, as well as the AWT behaviors, and have had a perfectly good experience with them.  In fact, I have found it to be *very* nice for partitioning off my behaviors.  Some behaviors wake up every frame, and some every third frame.  I can tune each behavior separately, as needed.  Depends on what it is being used for, I guess.

In our case, we are writing a strategy game, not an action game with a lot of animated stuff going on all of the time.  But there are multiple animations, particle systems, morphing behaviors, picking, etc. all going on.  Some of our behaviours are driven by external (e.g. network) events, and some by user input, and some by elapsed frames.  I haven't seen any "jitters", per se.  I am not entirely happy with the response time of the AWT event handling, but it has not been a big issue for our game, so far.

BTW, we are using Java3D.  

Offline Herkules

Senior Devvie




Friendly fire isn't friendly!


« Reply #4 - Posted 2004-06-26 17:09:43 »

Quote

As I do this sort of work for a living, I'm going to have to register a strong disagreement here.


Interesting to hear. I considered FlyingGuns to be a small thing ... there a single WakeUpOnElapsedFrame drives the whole game, all effects and so on....

Sure, you cannot control camera and a moving object it points to by different behaviours, just bc. of the jitter.

I felt that behaviors waking up on collisions or so would be used for large-scale applications giving a more autonomous habit. But of course that has been a guess.

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline cep21

Junior Devvie




Java games rock!


« Reply #5 - Posted 2004-06-27 02:12:40 »

Also add http://www.mojomonkeycoding.com to the list 3d for Java.  The developers are very active.
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Mr.CodeIt (13 views)
2014-12-27 04:03:04

TheDudeFromCI (17 views)
2014-12-27 02:14:49

Mr.CodeIt (25 views)
2014-12-23 03:34:11

rwatson462 (56 views)
2014-12-15 09:26:44

Mr.CodeIt (46 views)
2014-12-14 19:50:38

BurntPizza (92 views)
2014-12-09 22:41:13

BurntPizza (113 views)
2014-12-08 04:46:31

JscottyBieshaar (86 views)
2014-12-05 12:39:02

SHC (97 views)
2014-12-03 16:27:13

CopyableCougar4 (102 views)
2014-11-29 21:32:03
How do I start Java Game Development?
by gouessej
2014-12-27 19:41:21

Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!