3do: To be or not to be?

[Forboding Angel]

I'm not really suggesting anything here but I am curious. Does the code making 3do's possible have any significant impact in games that do not utilize 3do models?

In terms of engine performance for s3o and company (or just the engine in general), would the removal of 3do support have any tangible benefits?

[Kloot]

No and no.

[Gota]

and NO! XD

[Forboding Angel]

Chill gota, As I said, I wasn't suggestiong that 3do support be removed, I jsut wanted to know if it had an impact on games that only use s3o.

[Peet]

...Is 3do rendering actually notably slower than s3o or was forb talking out of his ass in that other thread?

[Das Bruce]

...Is 3do rendering actually notably slower than s3o or was forb talking out of his ass in that other thread?

I'm unsure, but is it really important? 3do is bad for a dozen other reasons.

[Beherith]

...Is 3do rendering actually notably slower than s3o or was forb talking out of his ass in that other thread?

I'm unsure, but is it really important? 3do is bad for a dozen other reasons.

It is, I would like to know as well.

[Kloot]

...Is 3do rendering actually notably slower than s3o or was forb talking out of his ass in that other thread?

No and yes.

(Even though I don't have to provide any justification to FA: 3DO's that use quads do need to be tesselated by the hardware, but those tend to be low-polygon anyway and Spring will never hit the vertex transform rate of any modern GPU unless BA switches to a 100K Flash. For both formats the geometry is d-listed, S3O's have more vertex attributes to support normal-mapping but they can be tri-stripped to save overhead. Also, unlike S3O's, all 3DO textures are atlased, which means only the atlas needs to be bound per frame as opposed to however many unique S3O texture-types are in use. And finally 3DO's and S3O's use the exact same shader setup, whose input is the d-listed geometry that has nothing to do with the respective model formats anymore. So, basically, the assertion "the models are 3do which causes huge complications in the vertex calculations department" is uninformed bullshit.)

[Argh]

So, basically, if Kaiserj or other parties build models that heavily use atlasing techniques as S3O, they should run quickly?

Question, since we're talking about this: aren't the number of Pieces the more likely bottleneck?

They're each a d-list send, aren't they?

Couldn't they be pre-optimized by converting the quads to triangles so they'd perform like S3O?

Not that I think that anybody should actually spend any time on this, frankly, nor on further tinkering with S3O...

[AF]

The geometry is already triangulated in the process of being sent to the GPU, if not in the process of compiling the commands to be sent to the GPU (display lists), as such the benefits and speed ups of 3do vs those of s3o are small, and it is mostly a convenience thing, and one of data formats, in that s3o allows a greater range of textures.

The two benefits of 3do are that you can speed up texture lookups because all units use the same OpenGL texture, and TA comparability, but these are advantages which are also present in s3o, and to a greater extent since you can make use of larger textures as your texture atlas, and 3dos can be converted into s3o.

As far as I am aware, both formats are read in and stored identically internally so once the model is loaded it all follows the same internal pipeline, any loss of performance would be from various branching statements, but since this is not the case it should not make much of a difference beyond the initial loading processes, although someone like jk or spliff would be the authority on this, any post by them should be taken as the authority on the subject

[Argh]

The geometry is already triangulated in the process of being sent to the GPU, if not in the process of compiling the commands to be sent to the GPU (display lists)

That is a fairly important distinction, hence the question.

My understanding was that gl.quadstrip was being used for 3DO, but it's been ages since I looked at that code, so maybe somebody got smart, built a preloader to break the quads into tristrips, and it uses the same rendering path as S3O other than preloading and a fixed atlas.

you can make use of larger textures as your texture atlas

Not unless you want to see problems on some ATi hardware and all the Intel stuff. 2048 is still the max for a lot of barely-compliant hardware.

Anyhow, just curious, I never intend to do anything whatsoever with 3DO after the nightmarish experience I had with the porting projects I tried out.

[AF]

Indeed but what I said is as true as ever

As for display lists, they do not transfer geometry over to the GPU memory for storage as that is the job of vertex buffers etc, rather display lists take a large chunk of commands, and prepackage them into a list of commands and data to be sent over to the GPU in one large chunk rather than lots if small fragmented chunks, which means things get faster. Triangulation would thus be performed by the drivers during the process of compiling/building the display list. Eitherway it is a fixed one time cost, and if it isn't, then there are optimizations to be made!

[jK]

DisplayLists can be saved in video ram, too.

[SpliFF]

The only real benefit of removing 3DO would be to simplify some of the engine code. 3DO has a significant number of branch statements in the unit rendering code dedicated to handling it. I don't believe any noticable performance gains are possible by removing these branches because they only build reusable display lists which are offloaded to hardware and therefore do not run continuously.

Many people who've given me feedback on my proposed engine changes felt 3DO support should stay. I agree in principle but my own view is that ultimately assets should be migrated to a more modern format (Collada and/or MD5).

However I'm not going to re-ignite that debate because I haven't completed any migration tools - removing support is currently impractical, even if it were really necessary.

On reflection the best way forward is to move the 3DO branch statements into proper class encapsulation were they belong. That way when the day comes that 3DO has no further value to the community it can be removed as easily as deleting its class files and making some minor adjustments to headers and build scripts.

[kremmy]

I feel that the discussion of whether to remove file format support is just a silly distraction from the problems that might actually exist regarding them.

Let's make this simple:

There is no reason to remove support for 'old', 'outdated', 'less functional' file formats. The only thing that is accomplished by removing support for old file formats is the breaking of content that makes use of those file formats.

The parts about game performance being affected by what file formats are being used is similarly silly. The data the (any) engine reads is, by the very nature of the simulation, used to populate internal data structures the engine uses. It doesn't just read the file and dump the contents into the video ram, it stores the relevant data in a memory structure optimized for what it is using that data for. This is just basic abstraction.

Chances are you would store a given piece of data in memory the same way regardless of the syntactical sugar of the file format you read the value from.

The answer was just posted:

On reflection the best way forward is to move the 3DO branch statements into proper class encapsulation were they belong. That way when the day comes that 3DO has no further value to the community it can be removed as easily as deleting its class files and making some minor adjustments to headers and build scripts.

If something you're suggesting doing to the engine would break a file format the engine uses, then something is seriously broken in the proposed modification or in the engine itself - but either way, a proposal to remove support for a file format is an ass backwards way of going about it. Fix the internal problem, don't blame the external data.

I'm not familiar with the Spring code myself. If it has some odd hackish stuff going on to support features of various file formats, and those aren't encapsulated under data loading routines where they never reach the other segments of the engine, then the abstraction is what needs to be worked on. Not a question of whether support for a data file format should be removed.

Think of something like Photoshop. Photoshop doesn't care what format your image data is in. It has a bunch of loaders which all read the various file formats and return the data in the format Photoshop wants it. You don't go writing code to handle the raw data format, you go parse that format to get the data you need to do what you're trying to do.

Summary:
I hear "This file format should be removed because the engine does some odd stuff to deal with the data read from it as well as not being as robust as newer file formats."
I respond "Fix the way the engine is handling the data so that the file format is irrelevant."
Because if there are hacks and other oddities to support something, you aren't going to be able to successfully rip it out unless you've fixed the real problem in the first place, and once the real problem is fixed you don't need to rip anything out.

[FLOZi]

I'm not familiar with the Spring code myself.

Which is where the problem with some of your assumptions lie

If it has some odd hackish stuff going on to support features of various file formats, and those aren't encapsulated under data loading routines where they never reach the other segments of the engine, then the abstraction is what needs to be worked on. Not a question of whether support for a data file format should be removed.

This is certainly something that I can agree with - but I should point out that work in this area has come on leaps and bounds recently (props to kloot especially).




Having said that, 3do does suck. And it's easy enough to convert to s3o. But I wouldn't really support the position of removing it, as I am totally opposed to the removal of s3o on the grounds of it being easy to convert to better formats, and I do hate to be hypocritical. I think, however, there may well come a time when no Spring mod still uses 3do. At which point it should be annihilated post haste, regardless of its non-effect on the engine, new content creators should never be lead down that particular dead end.

As for if a 3do is worse than an s3o, it depends if the cost of rendering doublesided is greater than the benefit (?) of atlassed textures. I'd accept anything kloot says at face value though.

[Forboding Angel]

Ack!!! No one said anything about actually removing it! I just wanted to know if the 3do code had an adverse effect on games that don't use 3do.

Why is this thread still alive? O_o

[Neddie]

I'll take that as a request for closure.