shared world environments?

[jon]

hello,

 

does anyone know of any 'shared world' systems that are animation: master friendly?

 

i'm thinking of something more along the lines of evercrack or there, as opposed to merely a networked fps.

 

thanks!

-jon

[gschumsky]

Not yet, since we're focusing on more of a 2D (using 3D art) isometric game engine. But what would be interesting is using something like this for what they're going to be doing for Sims Online. Also, there were some Shockwave based online "communities" where you could pick a character (which worked as your avatar) and you could mill about a hotel/mall type of world and you could talk to other "people" there.

 

With something more 3D, there might be a way to use Arctic Pigs... or maybe even a way for Avalanche to get into the picture since they now have a way to go directly from A:M (including scenery) into their own game engine. Wonder how much would need to be done to make it online playable?

 

Greg

[Paul Forwood]

A few questions for game developers:

 

Is anyone working on an A:M based game engine?

 

Are splines a valid medium for delivering game content? My realtime display says that they are and the certainty that games consels and PCs will continue to get faster, and more powerful, makes me think that a spline based, realtime game engine should be developed by someone. Maybe you know better and can educate me?

 

In general a polygon model will produce a larger file size than a spline model but what is the difference between them regarding computation time and rendering time? Which is faster and by how much?

[jon]

splines are ideally suited for shared 3d environments, due to the much smaller data transfer requirements. they can be displayed as hires as the target system will handle.

 

the geometry ultimately has to be converted to polys, but main and video processors keep getting stronger, so that really isn't an issue.

 

a simple pipeline from a:m to even a small-scale shared environment would be worth serious change to me.

 

-jon

[walasek]

Well speaking from some experience, as long as 3d card manufacturers do not support splines in their rendering pipeline, it isn't going to be very effective.

 

Think about it this way. All models must be converted each frame from splines to polys. You could pre-determine the polys (i.e. load a spline based model and then convert it to polys), but you would have to do that for every frame of the action that the model has ahead of time.

 

Converting from splines to polys isn't complicated, but it isn't on hardware, and will take cpu cycles away. The more models, the more cpu cycles. The more complicated the spline model, the more cpu cycles.

 

You would also have to worry about the textures and how they map from spline based models to the poly equivalent.

 

In my mind, its easier to convert ahead of time, make sure it all looks correct (mesh model and textures), and then just use the converted poly model and let the hardware do all the work...

[walasek]

I forgot to mention... There is an exporter of AM models and textures to the Genesis game engine (its a free 3d game engine - a bit old, but still usable for certain things). There is also the directX exporter which can be used to convert our AM models to directX models...

 

There also was an old way to convert to Quake models as well (it took a few steps, but some of the old quake I custom models were made with AM).

[Paul Forwood]

Thanks for the words of experience, Walasek.

So, if polys are always going to be the fastest method of delivering games graphics then I will rephrase my question.

Is anyone writing a dedicated A:M splines to polygons converter? I know about Milkshape and from what I understand it's a very awkward process. Is that still the best route?

[walasek]

Well, almost all exporters export to a poly based model. The real problem is that different game engines use different types of these models. DXF, OBJ, 3DS, DirectX are all based on Poly's (or mostly at least). It all depends on which format your game engine requires. Most newer game engines even have their own internal format (thats what I was referring to when I mentioned the Genesis exporter - its specific to export Genesis game engine models from AM).

 

Milkshape is a modelling and conversion program. Since it is free (or nearly so) a lot of people use it to create and convert models to make them available for different game engines.

[gschumsky]

Avalanche has a propietary game engine they use that turns splines into poly's, basically the same way Arctic Pigs works (actually A:M does this too for realtime playback as well as rendering). They model everything now in A:M and then go directly into their engine for output to various consoles. Now what's cool about this is that it's nothing really secret. All their code (or so I'm told) is based on the all the free Hash sdk and information on how the splines work (AP does the same thing basically). So, the building blocks for a realtime, online game engine are there. You just need a really good programmer, or need to be one yourself.

[ragtag]

Check out Second Life. It's a shared universe with built in editors you can create your own stuff with. Everything is streamed over the net as you go, which means you need a fast connection and good computer. I did an AM to SL tutorial for using AM to create animation for Second Life a while back. It needs updating, as BVH export works in later versions of AM, you just need to have some geometry attached to the bones to get the animation to export.

 

Of course, you can also upload your own images made with AM to Second Life. So there is nothing stopping you from opening your own AM gallery there.

 

Ragnar

[Sacman]

I wanted to bump this to start the discussion down a different path. I am studying Visual C++ right now and wow does it suck. What you can do with it doesn't suck but learning it does.

 

Everything I have read strongly urges the use of D3D and Direct X and to steer away from OpenGL for graphics. Particularly 3D. The Direct X SDK is free for download and includes so many of the basic 3d functions that actually render and show graphics that many of the steps needed are removed.

 

Also, Dirext X/D3D is owned by Microsoft. Apparently the OpenGL programmers are very slow at responding to the demands of the market and upgrades to Graphics Accelerator chip sets. Microsoft, as everyone knows due to how often we have had to update Direct X over the years, is apparently not as bad about this.

 

I do not have the direct X eporter but intend to buy it if it works as described. I hope to be able to get some tests run by someone that already has it before I buy. By using the Direct X exporter coupled with D3D then most of the problems are solved. Of course it would be great to import Hash .mdls directly into a graphics engine and watch it chug away but this is not going to happen anytime soon.

 

Maybe Avalanche will convert for you for a fee. Or better yet....make their source code available to the public as a plugin. If you are serious about game programming, it would likely be worth whatever Avalanche charged.

 

Thoughts??

 

Wade

[ragtag]

Good luck with C++, it's a pain to learn...which is why I never got very far with it.

 

The Obsidian Game plug-in works fine, and combined with Ultimate Unwrap 3D, you can convert the .x files to lots of different formats.

 

I'm surprised that everything you've read urges you towards D3D. For one thing, it's Windows only...which severly limits cross platform development. And frequent updates is not always a good thing. It means that you will constantly need to update your engine and code to work with the latest installment of D3D, and people using your game/software will need to download the latest DirectX version. It may have the most fancy features, but there is actually a lot you can do with DirectX 7 or 8 for instance, not to mention OpenGL.

 

Ragnar

[DrRIEGER]

Hello

I'm a bit surprized by the opposition almost everyone make between Polygons and Splines.

We indeed know that reducing the definition level of AM's reatime display gives a model that looks like Polygons. The .mdl file structure is therefore made of points, patches (succession of points that could be considered as polygons) and, yes, another item : spline continuity.

Many new game engines now take into account the Normal Mapping technique that is supported by the new GPU on graphic card boards. Everybody knows that Normal Mapping adds details onto a low polygonal model, like a one polygon per patch exported model from AM.

MDL model and Polygonal model have same numbers of points, same numbers of patches/polygons but the smoothness is done by spline for the first and by normal mapping for the second.

It appears to me quite the same thing, unless I'm wrong in detail I'd be pleased to discuss (in the limits of my knowledge).

 

About 'the ploygons as a fatal and final common way to hardware GraphicsCards' :

If I'm not wrong, DirectX in its v9.x edition (I do not remember the right sub-number x) supports Catmull-rom splines algorithm. I don't know if these splines can be turned into some kind of Catmull-Rom surfaces and if new graphics cards support the algorithm but that is an actual serious way to consider

 

Have a good day

 

From France,

Alain