Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (107)
games submitted by our members
Games in WIP (536)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1]
1  Java Game APIs & Engines / Xith3D Forums / Re: java3d to be opensourced on: 2004-03-28 01:30:39
Hey guys - I've been meaning to check in, but GDC got in the way.  Java 3D and Xith3D can co-exist with no problem.  Xith3D has a focus on games, and some non-games applications can take advantage of the things that it has.  There is also a very large Java 3D development community that doesn't make games.  Because of Java 3D's asynchronous multithreaded design, it fits very will into visualization systems.  It's focus is not likely to change because of its large visualization installed base.  So, having a games focused scene graph is a good thing.  There are lots of non-games Java 3D developers that are very excited about the prospect of helping to develop it.  The feedback has been awesome.

Also, it is unlikely that you will be able to directly use Java 3D code.  There is the license issue.  And, I think you will be suprised to find how different the code is than you might think.  It was designed for highly scalable multi-screen visual systems, so not much of the code will meet your needs anyways.

So don't worry.  Our intention is not to take over all scene graphs.  We are just trying to help our Java 3D developers who want to see it evolve and thrive.

Doug.
2  Java Game APIs & Engines / JOGL Development / Re: JSR 231 on: 2003-10-14 19:43:01
Quote
Cool... don't know the gentlemen whom I spoke with at Sun Network but they had no knowledge of this project - so that's where I draw my information from... walking up to Sun people and acting like a customer for the solutions that I'm developing and seeing what they say.


Keep doing it.  And that goes for everyone here.  Customer requests and needs have much greater weight than the ranting and raving of people who are on the inside.   Wink
3  Java Game APIs & Engines / JOGL Development / Re: JSR 231 on: 2003-10-14 17:45:26
Quote


I was talking to the hardware group - they are actively trying to sell graphics workstations and showing cool demos of those hardware platforms doing nice stuff in OpenGL. Since I know for sure that they sell into the government which uses these things for government simulation and training - it would be nice if they knew there was a Java solution already in place.


I used to work in that group, and they definitely know what is going on.  The problem is that most markets that they are working in do not currently use Java for their graphics applications.  Some are moving in that direction, but they are not there yet.  So, Java graphcis rendering is not at the top of their list of priorities.
4  Java Game APIs & Engines / JOGL Development / Re: JSR 231 on: 2003-10-14 17:43:26
Quote


Okay. So if I understand you correctly the J2ME OpenGL JSR, the JGI JSR and this new JSR 231 are the same thing or at least the same set of people?


There is no J2ME OpenGL JSR.  JSR-184 is the only 3D JSR for J2ME, and it is a high level scene graph API.  I am involved in that.  The JGI JSR is now cancelled, as it states on its page.  Those technologies are making there way to java.net.  I am involved in that.  And, 231 - which is the only JSR related to OpenGL has just been filed.  And yes, I am involved in that as well.

I work in the software CTO office.  I am the chief architect of the games group, and I am also focused on graphics strategies at Sun.  So, it is my job to know and help drive all of these activities.  I am very aware that lack of information is the biggest reason for all of this confusion.  I hope that we can make things a little more transparent, so some of the confusion can go away.
5  Java Game APIs & Engines / JOGL Development / Re: JSR 231 on: 2003-10-13 17:38:35
Quote


Then why not just focus the scope of the existing JSRs. Why are there pretty much 3 expert groups working on the separate JSRs? If SGI wants to go and work on their own, fine  - no biggie; but I still don't see any reason for JSR231. Where is this JSR going to diverge from the already existing JSR...s.



While there may not be any specific disorganization within Sun (though as an outsider talking to folks working at sun and in sun research I just can't understand why certain groups are unaware of these JSRs), the impression that is definitely coming from these proceedings is one of confusion and duplication.


There are no other JSR's for this activity.  There is only one JSR for Java bindings for OpenGL - 231.  SGI is not doing their own thing.  We are all working together.  I don't know where the impression came from that everyone is doing their own thing.

As I said, Sun is a big company.  JSR's do not become compleetly public until they are filed.  I don't know who you have been taling with, but it would not suprise me if some project off in a corner did not know what the games group is doing - we are only 6 months old.
6  Java Game APIs & Engines / JOGL Development / Re: JSR 231 on: 2003-10-13 16:00:10
Okay, relax everyone.  The games group is the group responsible for all of these actvities.  The intent is that this JSR starts with JOGL, and modifies as nessesary.  Becausr of the way the JCP works, you can't force anything on a JSR, so it could not be submitted as such.  There is no mass disorganization at Sun.  This is the result of the agreement between SGI and Sun.  SGI decided not to join the JCP, but will be involved - at a minimum through their involvement in the OpenGL ARB.

There is a focused strategy to all this - even though it sometimes is confusing.  Sun does not have lots of money to go around doing competing initiatives.  We are all focued on the same things.  Having said that, Sun is still a big company, so some people in the company may not know what others are doing.  That is not the case for any of the graphics technologies today.

Doug.
7  Java Game APIs & Engines / Java 3D / Re: Has Sun stop supporting Java3D? on: 2003-08-27 16:09:25
We have not dropped Java 3D.  We are still working on the future plans for the technology.  Once again, I appologize for the delay in getting complete plans out to the development community, but these things sometimes take much longer than we would like.  We have been listening to all the comments here and on java3d-interest

I promise that you will get an official announcement of our plans once they are finalized.  Thanks for your patience.
8  Java Game APIs & Engines / Java 3D / Re: Renderer design on: 2003-07-09 22:08:02
Quote
I forgot to mention that the transform to geometry flattening can happen behind the scenes when the renderer queues/caches up it's geomerty, if the "capability bits" were set as not writable, as you can set in J3D.

Doug, your are talking about writable transforms I am assuming...


Yes.  In fact, if you set all the capability bits correctly and compile the graph, Java 3D will flatten for you.
9  Java Game APIs & Engines / Java 3D / Re: Renderer design on: 2003-07-09 18:42:02
Quote


Doesn't this bottleneck go away if the updates are force to sync, i.e. all updates must finish before you fire up the renderer?  
A single pass bubble up of bounds or keeping a dynamic changes list to loop through is quite efficient.  This is how other game scene graph renderers handle it ( begins with "Ren" ends with "ware" ;-).

Forcing sync seems to prevent the bottleneck, no?

Also, if you still need/want async scene updates, then you can build a message system (a la Java3D) on top of this based sync-ed renderer... ("can build" meaning huge ass-kicking effort)


The force to sync definitle helps with the memory bloat, but the biggest factor on performance is how deep is your scene graph.  The composite transform computation will kill the renderer.  That's why hierarchical transforms are great for modeling, but horrible for rendering.

Java 3D is async, so it used the message passing system, and yes, it was a huge effort.
10  Java Game APIs & Engines / Java 3D / Re: Renderer design on: 2003-07-09 18:38:43
Quote
Hey Doug Smiley

I have what I think will be a blazing fast state sort design, but we will see.  Where do you think is the tradeoff between using geometry as the outermost sort versus shader sorting?

so

1. geometry -> texture -> transform -> (shaders like material, rendering attributes, etc)

vrs

2. texture -> shaders -> transform -> geometry

I was thinking that it wil have to be both, where I have the same geometry being rendered multiple times that I should use method 1, but for others use 2.

So, break the chunks into two bins, one which is where lots of duplicate geometry goes, which is then sorted inside by shaders for each geometry.  the second bin would pretty much assume that each geometry is different for each draw.

What has been your expereince?

Brad, I am supporting linked/shared groups from the start.  We use them a lot!


The next RenderBin I was architecting for Java 3D, had just this type of configurability.  If the RenderBin can configure itself to the current data set, then you have the best of both worlds because different scenes and different hardware characteristics (faster buses, longer shaders, less multipass) can be tuned for later.

So, it sounds like you are on your way.

BTW, with the bus being the big bottleneck these days, my guess is that with big scenes, you will have a bunch of 1's at the beginning.
11  Java Game APIs & Engines / Java 3D / Re: Renderer design on: 2003-07-08 23:43:11
Hi David,

Welcome to the world of writing scene graph renderers.  :^)  Here are my thoughts on your approach.

   - By making threading a non-issue, you have already solved most of your problems.  :^)

   - Transform updates and the resultant bounding volume structure update will require carefull optimization.  It is a simple concept, but it will quickly become a bottleneck.  All hierachical transforms for rendering should be banned.  

   - State sorting is very tricky, but it is the gold.  It will get you from a simple renderer to a real game engine renderer.

   - Beware of certain scene graph features, they are hidden daggers.  Examples include Link/SharedGroup and hierachical rendering state.

Other than that, have fun.  The initial design and prototype is very rewarding.  The last 20% will kill you.  :^)
12  Discussions / General Discussions / Re: Directions, LWJGL, JOGL, Signal and Noise on: 2003-07-08 22:57:18
I will mainly reiterate that we are here to try to solve game developer problems.  Some problems are easier to solve than others.  Some take much longer to solve than others.  We will update you with the most information that we can when possible.  

The most important thing you all can do is make great games and technology demos using Java.  If its cool, we will showcase it and give you some great press.  The more content the better.

As for Java 3D, it is not dead.  No one ever said it was dead.  Sun is a big company.  Different organizations have different priorities, and resources are tight.  We are working on the whole J3D issue to try and do what is right for the tremendous number of developers using J3D.  Just hang tight for a bit longer.  When we have an answer, you will be the first to know.
13  Java Game APIs & Engines / OpenGL Development / Re: LWJGL , Eclipse and SWT on: 2003-06-18 14:34:07
Quote


if you compare JOGL to LWJGL there is a *huge* difference, in the fact that LWJGL is much more (audio, input, math).

It would be more fair to compare JOGL/JOAL/JInput with LWJGL. And here the main difference lies in that LWJGL is meant for *games*, while JOGL et al. are meant for general purpose applications. Oh, and since it is supported by sun, it will probably become "pure java" while LWJGL won't (*sigh*)


The java.net technologies are meant for games.  And, I'm not sure what is meant by "pure"?  We removed public pointer access, but that is it.  If there is a case where lwjgl outperformes one of the technologies on java.net, then we should fix it.  So, I guess the question is what do you mean by pure Java, and why is that bad?

Doug.
14  Java Game APIs & Engines / Java 3D / Re: Law and Order on: 2003-06-18 14:25:50
I spoke with them about this last week.  They contracted out the port.  And the contractor ported the game to GL4Java.  If you have ever played the game, you know that the 3D usage is very minimal.

Doug.
15  Java Game APIs & Engines / Java 3D / Re: Mobile 3D Graphics API on: 2003-06-05 17:17:24
It is stalled.  We are looking at ways to get it going again.

Doug.
16  Discussions / General Discussions / Re: And so it begins.... ! (Sun makes play...) on: 2003-06-05 17:14:29
Okay.  So, a lot of what this new group is about is listening to game developers and getting things moving in the right direction for them.  We have a lot of ideas about what needs fixing, but we would like to see our list validated and updated with input from all of you.

So, what do you want to see fixed?  (With a new #2 pencil sharpened in hand)

Doug.

PS - Cas, we know about structs.  Smiley
17  Java Game APIs & Engines / Java 3D / Re: Mobile 3D Graphics API on: 2003-06-04 23:24:39
I said alternative - not replacement.  Java 3D is not going away.

Doug.
18  Java Game APIs & Engines / Java 3D / Re: Mobile 3D Graphics API on: 2003-06-04 19:01:50
I'm not directly involved in Java 3D development anymore, but I am involved in its evolution.  Java 3D 1.4 is in a holding pattern right now.  We are working on different possibilities.

We will be announcing alternatives next week.  Wink
19  Discussions / General Discussions / Re: And so it begins.... ! (Sun makes play...) on: 2003-06-04 17:54:08
[
Is there going to be a large push for getting Java technology on the client end as well?
20  Java Game APIs & Engines / Java 3D / Re: Mobile 3D Graphics API on: 2003-06-03 20:38:08
Me.   Smiley

How are you doing Shawn, see you next week.

Doug.
Pages: [1]
 

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

The first screenshot will be displayed as a thumbnail.

Riven (12 views)
2014-07-29 18:09:19

Riven (9 views)
2014-07-29 18:08:52

Dwinin (9 views)
2014-07-29 10:59:34

E.R. Fleming (26 views)
2014-07-29 03:07:13

E.R. Fleming (10 views)
2014-07-29 03:06:25

pw (40 views)
2014-07-24 01:59:36

Riven (39 views)
2014-07-23 21:16:32

Riven (27 views)
2014-07-23 21:07:15

Riven (28 views)
2014-07-23 20:56:16

ctomni231 (59 views)
2014-07-18 06:55:21
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
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!