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   
Pages: 1 [2] 3
  ignore  |  Print  
  Community Space Trader technical detail  (Read 30976 times)
0 Members and 1 Guest are viewing this topic.
Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #30 - Posted 2009-01-26 10:52:53 »

OK. loud and clear. The binding for JPCT I will add to JOODE will not be the same as the one we use in this project anyway.
How will people make art? They will use blender -> 3DS just for designing the meshes?

Tom

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
Offline SimonH
« Reply #31 - Posted 2009-01-26 16:01:06 »

How will people make art? They will use blender -> 3DS just for designing the meshes?
Good question! What format's best for you on the physics side? How can we keep the overall poly count down to playable levels?

People make games and games make people
Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #32 - Posted 2009-01-26 17:35:14 »

Well its fairly standard practice to have a lower polygon count for the collision mesh to help prevent the sporadic collision checks being a bottle neck. I have no idea whether they will be or not. I suspect collision detection will not be the bottleneck but rendering. If collision detection is an issue we can prevent AI ships from colliding with anything other than missiles with springs or something. Then really the only true collider becomes the player, and the missiles can be simplified to a point or something (i.e. the physics can be tuned pretty easily).

I think our major time saver will be rendering far away ships as really low dimensional poly's eventually simplifying them to be a single triangle of roughly the right color when miles away from the camera.

So how the question is whether the artists have to be responsible for producing different resolution polys or whether we try to do that automatically. (option 1 is hard on the artists, option 2 is hard on the coders)

Quote
What format's best for you on the physics side?
Oh its doesn't really matter. As long as I can get at the mesh verteces to build trimeshes it does not really make much odds.

I think making the artists job the easiest is the best direction. I dunno how people will use procedural texture generation and be able to model in a gfx program at the same time (unless we have a blender plugin or something)

Tom









Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline SimonH
« Reply #33 - Posted 2009-01-26 18:22:27 »

Well its fairly standard practice to have a lower polygon count for the collision mesh to help prevent the sporadic collision checks being a bottle neck. I have no idea whether they will be or not. I suspect collision detection will not be the bottleneck but rendering. If collision detection is an issue we can prevent AI ships from colliding with anything other than missiles with springs or something. Then really the only true collider becomes the player, and the missiles can be simplified to a point or something (i.e. the physics can be tuned pretty easily).
Cool, rendering is definitely the biggest problem!

Quote
I think our major time saver will be rendering far away ships as really low dimensional poly's eventually simplifying them to be a single triangle of roughly the right color when miles away from the camera.
So how the question is whether the artists have to be responsible for producing different resolution polys or whether we try to do that automatically. (option 1 is hard on the artists, option 2 is hard on the coders)
No such a problem (hopefully), I'd already thought of some form of imposting (ie pre-rendered images) for more distant objects, so I guess that a single low-poly model will do from the artists. I wonder about ships breaking up though (especially large ones) - we'll need some way of splitting the mesh when a ship explodes... I looked into voxels but no way we've got the CPU beef to do it!

Quote
I think making the artists job the easiest is the best direction. I dunno how people will use procedural texture generation and be able to model in a gfx program at the same time (unless we have a blender plugin or something)
I've a feeling you're right, but we'll have to heavily stress the low poly/small texture requirements!


People make games and games make people
Offline bobjob

JGO Knight


Medals: 10
Projects: 4


David Aaron Muhar


« Reply #34 - Posted 2009-01-26 18:57:24 »

all the models for the RTS are going to be very low poly (as high polies are not needed in any way). Also I will be making calapsed versions of the polies, (these probably wont be UV mapped as there going to be so small, so texturing will be disabled and they will be rendered in the dominant color.

A primary mesh will have a poly count like the model update I posted.

I still really feel that sharing space ships between each project will be a good idea for productivity.

My Projects
Games, Webcam chat, Video screencast, PDF tools.

Javagaming.org with chat room
Offline SimonH
« Reply #35 - Posted 2009-01-26 19:15:51 »

all the models for the RTS are going to be very low poly (as high polies are not needed in any way). Also I will be making calapsed versions of the polies, (these probably wont be UV mapped as there going to be so small, so texturing will be disabled and they will be rendered in the dominant color.

A primary mesh will have a poly count like the model update I posted.
I still really feel that sharing space ships between each project will be a good idea for productivity.
Sure thing - the more common resources the better!
BTW could you post the 3DS file for the Manta so's I can check the JPCT loader? All being well I'll put it in the feasibility test applet.

People make games and games make people
Offline bobjob

JGO Knight


Medals: 10
Projects: 4


David Aaron Muhar


« Reply #36 - Posted 2009-01-26 19:56:11 »

Here is a link for the manta model.
manta.zip
The zip file includes:
primary ".obj": mesh
low poly ".obj": extremely low poly (I use this for long distance objects). It could also be used for collision checking.
manta.jpg: primary texture map
manta_h.jpg: height map used with shaders
manta_n.jpg: normal map used with shaders

edit: Sorry its not in 3DS format, I use obj in my game. Blender can convert from obj to 3DS, in case you needed to.

My Projects
Games, Webcam chat, Video screencast, PDF tools.

Javagaming.org with chat room
Offline SimonH
« Reply #37 - Posted 2009-01-26 21:10:27 »

Cheers bobjob! Seems to be some problems with the JPCT loaders though (even with jpct-supplied 3ds files) Sad

BTW Must-read article on procedural textures for planets!

People make games and games make people
Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #38 - Posted 2009-01-27 13:41:41 »

yeah cheers bobjob

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
Offline SimonH
« Reply #39 - Posted 2009-01-27 17:23:27 »

Whew! It was a struggle but I finally persuaded JPCT to play along - new feasibility test with the Manta in wobbly orbit.
NB: JPCT can only handle 256x256 textures. I haven't done any texture-alignment tests yet...

EDIT: someone just pointed out that the thread title is spelled wrong! Hmm... how do you amend a thread title?

People make games and games make people
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Jono
« Reply #40 - Posted 2009-01-27 20:06:50 »

EDIT: someone just pointed out that the thread title is spelled wrong! Hmm... how do you amend a thread title?
Ooo!! I know this one!  Grin Just modify the first post and change its subject.
Offline SimonH
« Reply #41 - Posted 2009-01-27 21:22:27 »

Ooo!! I know this one!  Grin Just modify the first post and change its subject.
It works! Thx!

Just checked & JPCT seems to handle texture-mapping correctly.

People make games and games make people
Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #42 - Posted 2009-01-28 13:54:46 »

Quote
new feasibility test

60fps on my Linux laptop using the software openGL renderer (my gfx card is broken). Very very nice.

Erm, could you upload your source to the svn repository. Just whack it all in a directory called feasibility test 1 or something, no need to tidy. (or post the source in a zip somewhere here). 

I'll use it as a base for the physics development at the weekend.

Tom

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
Offline SimonH
« Reply #43 - Posted 2009-01-28 16:50:35 »

60fps on my Linux laptop using the software openGL renderer (my gfx card is broken). Very very nice.
Hmmm.. It's locked to 60fps max but I only get 35fps here - we may need to keep an eye on this, maybe lock to 20fps or something?

I've added an attempt at particles, not sure this is the best way to do it.
Source code here (and no scoffing at my coding!).

People make games and games make people
Offline dishmoth
« Reply #44 - Posted 2009-01-28 19:52:34 »

Hmmm.. It's locked to 60fps max but I only get 35fps here - we may need to keep an eye on this, maybe lock to 20fps or something?
60fps for me, and rather cute it looks too!

Offline SimonH
« Reply #45 - Posted 2009-01-28 21:40:03 »

Bit of tinkering with procedural textures (source here).
Looks quite nice, but JPCTs spherical mapping seems a bit odd...

People make games and games make people
Offline bobjob

JGO Knight


Medals: 10
Projects: 4


David Aaron Muhar


« Reply #46 - Posted 2009-01-28 22:29:32 »

Bit of tinkering with procedural textures (source here).
Looks quite nice, but JPCTs spherical mapping seems a bit odd...

maybe also try use the decimated version of the model (in the zip i sent), rendered with a color value of r=0.5 g=0.5 b=0.5
or even maybe use the current model, without a texture, just the static color, when its far from the camera.

My Projects
Games, Webcam chat, Video screencast, PDF tools.

Javagaming.org with chat room
Offline SimonH
« Reply #47 - Posted 2009-01-29 18:53:15 »

A bit more tinkering: a couple of tracking cameras (& probably the worst starfield bodge ever perpetrated!)

People make games and games make people
Offline moogie

JGO Knight


Medals: 12
Projects: 6
Exp: 10 years


Java games rock!


« Reply #48 - Posted 2009-01-29 21:30:20 »

Smiley it is starting to look like a space sim.

I find it odd that JPCT is rendering the space craft when it is obscured by the earth. (in wire frame mode)

It seems like a candidate for performance slow down when many objects on the screen.
Offline Jono
« Reply #49 - Posted 2009-01-29 22:16:38 »

A bit more tinkering: a couple of tracking cameras (& probably the worst starfield bodge ever perpetrated!)
I get some slightly odd behaviour - it's like the JIT is taking a really long time to warm up. I start with around 5 fps, this slowly increases and after about 10s it reaches 20 fps. I hit 60 fps after about 15-20s.

The other weird thing is that hardware rendering ought to be working, so the JIT shouldn't be having such a bit effect anyway. Regardless, once it's all warmed up it looks right nice  Smiley
Offline Mr_Light

Senior Member




shiny.


« Reply #50 - Posted 2009-01-29 23:01:47 »

I get some slightly odd behaviour - it's like the JIT is taking a really long time to warm up. I start with around 5 fps, this slowly increases and after about 10s it reaches 20 fps. I hit 60 fps after about 15-20s.

The other weird thing is that hardware rendering ought to be working, so the JIT shouldn't be having such a bit effect anyway. Regardless, once it's all warmed up it looks right nice  Smiley

I could be totally off here but since it doesn't request any privileges it must be doing software rendering.

I noticed the wireframe thing too, what 'bothers' me more is the sharp edges though - they don't 'blend' well. Perhaps this is easily solved, not really my cup-O-tea

It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #51 - Posted 2009-02-01 03:11:47 »

Urgh, 'tis 2.07 a.m (was 9p.m.).

JOODE is almost intergrated with JBullet (though not svn uploaded yet). I havn't managed to actually run any code yet becuase I have not finished the JPCT bindings yet.

If I feel like neglecting my PhD for another day I'll do that tommorrow, but I have done my 4 hours (+) of commitment so it might have to wait till next weekend.

Tom

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #52 - Posted 2009-02-01 19:09:45 »

Right well I did a bit more today (Sunday). I've committed the work so far into JOODE's SVN in a subdirectory called jbullet. Its a bit of a pain working with JBullet because it requires additional post compilation mucking about through ant, so development cant really be done 100% in my IDE. Anyway, I have no idea if anything work until I get the JPCT bindings working. Currently they don't so probably nothing else works yet, so I don't advise even looking at the source I have produced yet.

Tom

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
Offline moogie

JGO Knight


Medals: 12
Projects: 6
Exp: 10 years


Java games rock!


« Reply #53 - Posted 2009-02-01 21:53:00 »

And i have been implementing a raytraced render... To begin with i started using my existing raytracing engine framework however since i had designed it in logical abstractions and heavily object oriented paradigm it unfortunately is not speedy enough.

So I will be creating a more procedural based engine which hopefully will be much faster. I should imagine that it will not be a mammoth task as i can re-use code and algorithms from my existing engine.

Offline SimonH
« Reply #54 - Posted 2009-02-05 02:18:38 »

Moogie: Good luck! I reckon you'll break new ground if you can get it fast enough!

Tom: How does JBullet bind to a renderer? I know JPCT pretty well so maybe I can help with that?

People make games and games make people
Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #55 - Posted 2009-02-06 00:21:37 »

 svn co https://joode.svn.sourceforge.net/svnroot/joode/trunk joode

you will find a subdirectory called jbullet. This has 4 sub directories containing source code.

1. jbullet-src contains the jbullet source as is (do not edit).

2. src contains the main JOODE adapter to jbullet. This probably doesn't work becuase I can't see the results yet.

3. JPCTbinding. Contains only three classes. JPCTBinding is a live binding to a JBullet geom. JPCTManager which listens to geom added events and creates (and destroys)  bindings accordingly. And JPCTConverter which is the hardest part to write. This class creates a JPCT graphical representations of JBullet geometry classes. Currently I am only trying to create spheres for JBullet's SphereShape, but it will be where all the action is eventually. The class structure is pretty much identical to the Xith binding. Writing converters are not hard, but can be time consuming and fiddly getting everyones concept of position lining up. We should get Spheres working, then off-center spheres and then probably jump straight to meshes.   

4. Finally there is a test src directory which is where a TestingWorld resides, which will be a super class to all tests that involve JOODE-JBullet-JPCT functionality. TestingWorld currently makes the correct connections between JOODE's dynamics and JBullet's collision engine. It also instantiates a JPCT World. At the moment in the main I create a JOODE body and connect it to a Sphere, and add these to the dynamics and the collision world, which should cascade via GeomAdded events to the JPCTbinding. Once TestingWorld is rendering properly, then a specific subclass involving colliding Spheres should be created. (and then meshes etc.)

Currently the converter does indeed create the graphical object. But somewhere in the graphical setup nothing gets rendered. I have not instantiated any threads or anything. I ran out of development time last week and I am inexperienced with JPCT so no doubt I just havn't set things up properly or set the renderer running. I am sure you could help. I was gonna copy how your demo works on Sunday, but if you think you can help that be great.

So getting the TestingWorld to render a sphere in the test src directory is the priority at the moment. All the event model etc. is probably garbage at the moment, but I can debug that pretty quickly once I can see Smiley, it is working enough at the moment to add geoms. Oh yes, adding mouse movement and key board inputs would be great too. Look at the Xith TestingWorld to see the kind of functionality I am trying to reproduce. (PS dynamics is stepped via world.step(x), all geometry should be updated automatically but that might not work yet)

Tom

 

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #56 - Posted 2009-02-06 00:29:28 »

Oh yeah and....

JBullet uses this brilliant yet annoying method for object pooling requiring a post compilation instrumentation step. So run the testing world via the ant task in the build.xml in the root of the jbullet subdirectory: "run-JBulletTestingWorld".

When I decide to integrate JBullet a bit deeper I will be getting rid of that. At the moment I don't want to alter JBullet src.

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #57 - Posted 2009-02-09 01:16:10 »

Well I dunno if you ever got round to checking out my JBullet wrapper. I just noticed it was missing loads of libraries needed to run. Anyway the whole lot is in there now I hope.

The initial testing world now manages to move a sphere is response to gravity. I haven't tested collision functionality yet (but this demonstrates JPCT and JBullet are in sync with JOODE). The jstackalloc dependency is driving me nuts so next week I shall get rid of that as my top priority. Thats quite alot of jbullet source code modifications though for no noticeable change in functionality, but it will increase future development productivity 10 fold.

It probably wasn't 4 hours work, but I am a bit sick this weekend. I'll try to be more productive next weekend.

Tom






Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
Offline SimonH
« Reply #58 - Posted 2009-02-09 21:15:36 »

I have looked at it but I'm not sure how you're doing this!
JPCT really hates adding/removing objects; ideally all objects are pre-loaded prior to the first rendering, but your code seems to add/remove objects frequently?

People make games and games make people
Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #59 - Posted 2009-02-09 23:01:14 »

My code will call jcpt.addObject() every time a new collision shape is added to the environment. I call the shape.build() once and clone shapes from cached primitives, but you are suggesting I should add them to the jcpt world upfront? How to I make sure they are not rendered until I want them to be? setVisible?

Anyway, my code adds objects as they are added to a CollisionWorld. So as long as you do that before starting your rendering thread then that will be done before any rendering occurs. It looks like spagetti at the moment because its event driven (and JBullet is adapted rather than modified), but once I get proper test cases you will see that the binding system JOODE uses means you don't have to explicitly do any rendering code yourself, other than picking your binding and setting up the display. The JCPTManager ensures new objects have a rendered version, and destoryed collision objects removes the rendered version. Oh maybe you have just not got my code. New objects are not created every world step. Only the transforms are updated. Its a bit of a pain at the moment becuase Jbullet uses one set of Math classes, JOODE another and JPCT another so they all need to be converted between each other every world step. This is all done without garbage being produced, so apart from the *exceedinly minor* performance and memory hit its not a massive issue.

Maybe I should explain some concepts:
a JOODE dynamics World emits world step events every time step. It also emits Body added/destroyed events when a dynamics object is added or destroyed.

JOODE collision spaces ~= JBullet's CollisionWorld (which is adapted to give the event model) emit geom added/destroyed events when a collision object is added or destroyed.

graphical bindings: currently Xith and JCPT called XithManager or JCPTManager are instantiated on a collision space and world. They listen for Geom added events or destroyed events to create live bindings to collision functionality. They listen to world step events to know when to update their local transformations on the current live bindings.

The JBuller adapter functionality looks a lot like a binding in many ways, because it too listens to world step events and updates the jbullets representation of position every time a body moves. A BodyInterface allows CollisionObjects (JBullet concepts) to be associated with  dynamic bodies (JOODE). Its at the point of association that a listener is created to keep those associations in sync (note only one listener ever instantiated per world, that one listener updates all associations for that particular world per world step).  JOODE will be converted to run off openMali sometime in the medium future, so eventually all this listening to step events will not be needed for the JOODE JBullet interactions. But I need to test JBullet before I can start integrating it deeper, so this superficial syncing is the best initial move.

Tom 





Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
Pages: 1 [2] 3
  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.

CogWheelz (11 views)
2014-07-30 21:08:39

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

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

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

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

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

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

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

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

Riven (30 views)
2014-07-23 20:56:16
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!