Community Space Trader technical detail

Business and Project Management Discussions Community & Volunteer Projects
#1

Ok, new tech thread to save clutter on the main thread.

Story so far: Physics looks to be pretty much under control, but we need to find the best solution for software rendering.

Suggestions so far;

  1. Off the shelf: Pros: Tried and tested, easy(ish) to implement. Cons: Maybe too generalised or too bloated.
  2. Custom renderer: Pros: bespoke visuals & specialFX, compact code. Cons: Technically difficult to do well, time consuming.

So how do we get the most bang for our bucks? Is raytracing the way to go?

EDIT: Title spelling corrected ahem

#2

My vote is off the shelf ray-tracer (research needed). I think bloat can be managed with tools. If bloat is such a massive issue we can fork an external project.

#3

I think ray-tracing performance isn’t quite there yet. May be a possibility by the time we are actually finished.

Note from the Quake3 Raytraced:

runs faster with more computers (about 20 fps@36 GHz in 512x512 with 4xFSAA)

512x512 20fps requires 36GHz!

#4

JPCT is the best bet. No bloat, tried and tested and ready to go.

Kev

#5

true, however modern raytracers are a bit better, here is a game using a ray tracing engine I is playable on a laptop using a core 1.3 ghz cpu at lower resoultions.

#6

I would like to put my hand up for working on the planetary body generation/rendering side of things. I spent quite a bit of time doing planetary rendering when I was working on this.

Maybe a vote is required but the options I see are:

Custom RayTraced
Custom Scanline
JPCT
LWJGL
Ardor3D/JME

I reckon it would be pretty cool to be one of the first big projects using Ardor3D.

#7

One of things that was part of the aim early on was providing a software only version of the game for casual players (i.e. no security pain dialog applets). LWJGL stop that, but of course we could have two versions of the client.

However, JPCT would give this abstraction of rendering without any effort. Should the focus be the game and not the renderer?

Kev

#8

yeah,

perhaps we should do the tried and true rendering and focus on game design and game play. As most 2d games show… if the game play is great, graphics can be not the best. e.g. Liero.

or if we abstract the render we can plug in different renders if some one wants to write a different 3d render… hehe someone could create a 3d ASCII render as a joke.

#9

[quote=“kevglass,post:7,topic:32838”]
Why do red sports cars sell x2 compared to black ones?
Of course the game is vital, but so is the look. Can’t we have both? I’m kinda resigning myself to using jPCT as I know it well, it’s free and it’s stable, but I think at this early stage it’s worth investigating the alternatives to see if we can’t get that ‘wow’ factor. I want people impressed as soon as they see the game, when they’ve played it I want them to be REALLY impressed! If we aren’t going for top-drawer then why bother at all?

#10

Perhaps we should have two parallel rendering development streams with one using jPCT to allow the development of the game and one experimental render stream.

The experimental render stream should only have minimal people assigned so that its development has no impact to the other aspects of the game.

#11

Absolutely agreed, but that has very little to do with the renderer (since most renderers produce similar results intentionally, since thats what the player expects) and far more to do with the art content being consistant, professional and impressive.

Kev

#12

[quote]if we can’t get that ‘wow’ factor.
[/quote]
What technical graphical features provide wow? Dynamic lighting (JCPT has)? Reflections (dunno)? particles (JCPT has).
While a space game is probably the best scenario for ray traceing, I don’t think there are any suitable off the shelf ray tracers. I think rolling our will be too large a task. Compare the features list of JCPT with rings http://j3d.sourceforge.net/, WE would have to fill that gap.

Yeah I totally agree that the gameplay and actual graphics is more important than the rendering technology. However, you can’t code a thing until you know what form of data you will be working on. JCPT implies MD2 for example. I think JCPT is a great option if just for the turn on/turn off openGL acceleration. It seems to support alot of extra features we will need as well.

With rendering and physics decision made, a subset of functionality can be developed independently of thematic story (e.g. moving a ship around, shooting, crashing it into another and drawing it). Those operations are not trivial, particularly non-convex poly-poly collision checks. I’ll have to split the polys into convex pieces no doubt. All my initial time will be swallowed by getting those tasks working correctly, so its better I get on with that ASAP. It doesn’t matter with those tasks whether the game contains RPG stats or not. I need to know what model format the graphics will be in so I can ensure the physics ends loads the meshes correctly. I’ll assume MD2.

Tom

#13

JPCT loads 3DS also I think, might make more sense for a space trader:

Probably pretty easy to port one of the model loaders from another scenegraph if it becomes a problem.

Kev

#14

Would there be point in using voxel graphics?

#15

Dunno what voxel graphics are in the context of games. I have used them for medical imaging, but thats so you can take slices of objects.

3DS format you think is best. OK.

Yeah I am just thinking about collision stuff now. I have been going over the Bullet/JBullt JDK and yeah, its way better collision detection than ODE/JOODE. So with that in mind I am gonna seperate out the current collision library from JOODE (its kinda designed for that anyway) and plug in JBullets (which is also what the ODE community have done). Ooooooh sexy collision routines between smooth objects! That work will be done in JOODEs repository so I can just get on with that. ETA 2 weeks? (8 hours, maybe thats optimistic, I’ll keep you updated on Sundays).

Tom

#16

Quick feasability test of JPCT.
NB JPCT also supports collision detection. For some strange reason the +Y axis goes down…

#17

Nice test. Good work :slight_smile:

#18

For example Outcast used them for outdoor landscapes, C&C: Tiberian Sun and Red Alert 2 used them for most vehicles, Crysis uses them for its terrain system (see this video at 4:30). Some more are mentioned here: http://en.wikipedia.org/wiki/Voxel#Computer_gaming

I don’t know about the performance requirements or technical details of using voxels. I just know that not too many games use them, so they would at least be something different, whether in good or in bad.

#19

crysis uses voxels only in the terrain editing tool. The end result is a triangulated mesh of the voxel representation. Voxels are often used for destroyable terrain experiments but they make many things difficult compared to regular heightmaps (like texturing, some engines use only voxel coloring since realtime triangulation and texturing is expansive).

Outcast is the only game I know which used a voxel terrain engine at runtime. But AFAIR they had no terrain textures too only colored voxels.

anyway voxels would produce a unique look of the game, maybe its even a good decision to try something different.

#20

JCPT or whatever the acronym only supports poly - primitive tests. If it did support poly-poly (which it doesn’t but few gfx engines do) it would only be convex convex polygons.

cool demo.