Question Why not looking out for an external engine?

[Nerull]

Actually, I'm looking at MSFS. I think that's a perfect example of how NOT to do things.

I have an e8400 C2D processor overclocked at 4.2 ghz, 4 GB of RAM and a HD4850. And FSX runs like ****. I had to set the details on medium and spent several hours recompressing the textures of the damn thing to get a half decent framerate (medium of 20 fps). So I still play FS 2004 and hope the next version of FS will be better optimised... Or i'll get better hardware and finally get a decent performance in X.

While at it, probably most of you know those FAMOUS Genesis vids, with all the smooth transitions from space to the planet's surface and viceversa. How the hell did they pull that crap off? And are there any chances of seeing something like that in Orbiter anytime soon?

Sounds like there is something wrong with your system. FSX should perform great on those specs. I've run it on high with a 1.5Ghz Athlon and a GeForce 6800.

 

[Jake]

What I forgot to mention is that I push the air traffic and most non-graphics related settings all the way to the max . It's the graphics settings that are really weird. Bloom for example is so badly implemented that it clogs up nearly any system. I always kept that off.

Other than that, I don't know. I tweaked all the settings I could in the BIOS to get an overall better performance. I don't think my system has any problems, since I can play any other game in optimal conditions. I thought about something loading my system, I tried the game on both XP and Vista, it runs the same.
Still, when I'm on the ground or close to it (especially in highly populated areas, such as LA or Tokyo) the framerate really drops. When I'm in the air at higher altitudes things are acceptable.

However, the game IS horribly optimized. Some time ago I checked the charts on Tom's Hardware. Even on the highest end of the high end cards, the game barely went over 30 fps with AA turned off, on 1280x1024.

 

[cjp]

A procedural terrain algorithm for Mars is completely different to the one for Venus or Titan. And gas planets would go better with volumetric cloud layers.

My idea: use a terrain engine with a plugin system (with different code for different scales, different planets and maybe even for different terrain types on the same planet). And make some generic plugins that accept parameters in .cfg files: e.g. all bodies without atmosphere or tectonics can have the same plugin, but with different crater statistics and color distribution.

Now I should really start working on this idea. If only I had as much time as ideas...

 

[Artlav]

My idea: use a terrain engine with a plugin system (with different code for different scales, different planets and maybe even for different terrain types on the same planet).

That's essentially how Orulex worked - a unique function is defined in cfg for every planet.

Now, that's too slow for a new version, so it uses a pre-compiled functions, which could be exported to plugins. Good idea.

 

[th3flyboy]

Hey guys, I've been away for a while from orbiter, but I figured I'd get back in to it, then I saw this thread. May I point out OGRE guys... It's pretty much Graphics only, not physics (unless you use a physics engine plugin), and it works with OpenGL, DX9, and DX10.

http://www.ogre3d.org/

Anyone wondering why I left and why I returned, well that's for another thread...

 

[Urwumpe]

Will it be anything better than for example Artlavs OGLA engine for the next version of Orbiter?

I am sure: not.

 

[mdg583]

Has anyone looked at Magrathea? I don't know much about it, but I thought I'd throw the idea out there.

 

[ToanPhuc]

Hey guy.I have the question that what is the big difference bettwen Orbiter engine and other OpenGl engine?I think physic simulate can do by programming language and leave the graphic for a special graphic engine?

 

[Hielor]

Hey guy.I have the question that what is the big difference bettwen Orbiter engine and other OpenGl engine?I think physic simulate can do by programming language and leave the graphic for a special graphic engine?

The big difference between Orbiter and other OpenGL engines is that Orbiter isn't an OpenGL engine.

 

[tblaxland]

The big difference between Orbiter and other OpenGL engines is that Orbiter isn't an OpenGL engine.

I'll rephrase the question then: what is the difference between OGLA and some other OpenGL engine (eg, Ogre3D linked above)? This is no criticism of OGLA, btw, I am just genuinely curious as I have very little knowledge of such high end graphics programming.

 

[Artlav]

I'll rephrase the question then: what is the difference between OGLA and some other OpenGL engine (eg, Ogre3D linked above)? This is no criticism of OGLA, btw, I am just genuinely curious as I have very little knowledge of such high end graphics programming.

OGLA is more special-case. It fits Orbiter perfectly.
Compared to the OGRE3d, it does not have the goal of being in any sense universal, so it's spared the complexities of a million interfaces and compromises.

Think space suits - Ogre3d will be an one size fits all, bulky pressure suit, OGLA will be a tight-fitted space activity suit.

 

[tblaxland]

Think space suits - Ogre3d will be an one size fits all, bulky pressure suit, OGLA will be a tight-fitted space activity suit.

Makes sense, thanks.

 

[ToanPhuc]

Can we use Panda3d and Delta3d,the two new free graphic engine that support both openGL and Direct3d?

 

[Vanguard]

Perhaps we could clear a few things up in regards to what OpenGL and DirectX are. Just because something uses one or the other doesn't automatically give it a certain "appearance". You could look at 20 different games all programmed using OpenGL, and they will all provide different levels of details and "bling-bling". Just because they all use OpenGL doesn't mean they even look remotely close to each other.

The best way to explain it would be, OpenGL and DirectX are a set of tools (i.e. specialized paintbrushes) which paint on the screen. Developers use these tools to paint the screen in whatever fashion they choose. Some developers are simply more comfortable and used to one set of brushes (API) over the other... either one should be able to produce the same quality. Each one however, also provides a set of macros for making the job of the developer easier. Some macros are "bulkier" than others, and some produce nicer effects than the other. These are for free, however all of it can be done from scratch if you feel like it.

Something like Ogre3d is a robotic paintbrush already ready to go. Its "bulky" because it contains a lot of functionality we don't need, and is not specialized to the task at hand. On the other hand, it's very powerful and does contain almost everything that may be needed... (which a lot we don't... hence bulky).

So in reality:

Think space suits - Ogre3d will be an one size fits all, bulky pressure suit, OGLA will be a tight-fitted space activity suit.

Ogre3d is a bulky pressure suit, but OGLA is a tight-fitted space activity suit that only contains the functionality that Artlav has the knowledge to produce (which may be a ton... I'm not judging here)

Ultimately though, the real issue with performance is not which toolkit you use, or even how you choose to draw it. The thing that sets aside one program over the other (think FSX here ) in terms or performance, is how the developer of the engine organises the data and what they decide to draw and when.

Using Doom as an example here to clarify the last paragraph... The developer has a building they need to "paint". The developer could simply decide to paint the entire building (every wall, door, etc). If you're standing in a room with no windows and a closed door, you've wasted a PAYLOAD of CPU drawing a bunch of **** no-one can see anyway. What doom did to optimize this is: once the blueprints for the building were complete (the map for the level), it organized the objects in the game, (wall, doors, plants, whatever) so that from each room, it knew what the user would be able to see, and limited its "painting" to only paint the relevant objects. This is what made it fast for its day.

So, whether you painted it with OpenGL, or DirectX, Artlav wrote it, or Artlav implemented it with Ogre3d... the performance and eyecandy factor falls into how he used the paintbrush, and what and when he decided to paint each object... Weeeee....

BTW: The reason FS is slow as hell (all versions) is because at 30,000 feet, you have a lot of **** to paint! There are no rooms, its one big outdoors... And orbiter is bigger than that. When orbiting earth, you don't want to waste your time "painting" neptune with level 11 when it appears as a dot on the screen.... This is where the developer needs to organise the data and choose a smarter way to paint an object without killing your poor CPU.

 

[Raistlen007]

infinity engine

I saw this youtube video a few years ago of a proof of concept for an engine that renders both space objects and planet surfaces and everything in between.

This is the kind of graphics i'd like to see in orbiter. I know that implementing this specific engine into orbiter isn't an option for various reasons, but I would just like to point out that making that kind of engine is possible, and keep in mind this video is very old.

 

[RisingFury]

Can we use Panda3d and Delta3d,the two new free graphic engine that support both openGL and Direct3d?

Oh for the love of God...........................


I mean... you gotta respect Martin for not losing it with all the worthless suggestions and hair-brain ideas that have no merit...


I mean... didn't Artlav make the argument why no generalized graphics engine could never work for Orbiter just 2 posts before yours?

What doom did to optimize this is: once the blueprints for the building were complete (the map for the level), it organized the objects in the game, (wall, doors, plants, whatever) so that from each room, it knew what the user would be able to see, and limited its "painting" to only paint the relevant objects. This is what made it fast for its day.

Binary space partitioning?

 

[Moach]

two engines i´d recommend and why:


1. DXStudio - it´s a british engine built for general purpose game development - it´s not free nor open source, but the license is *relatively* cheap and it can be freely extended with an C++ SDK...

it also makes a LOT of things VERY easy, DXS is built with the SpiderMonkey javascript1.8 engine, which makes for some pretty easy programming (specially for addons) - it also features a layer-based approach which allows 3d renders to be overlapped, which would enable one to use different layers for rendering the VC, near objects and far-away things...

also, making 3d things interactive in DXS is as easy as if they were 2d... it has a built-in raycasting system which automatically detects mouse events over any object

unlike most other platforms at it´s price range, DXS can be greatly addon-friendly - and it can deal with meshes in .x format, through a easily integratable commandline importer, or meshes can be exported straight into it´s own zip-compatible format via the DXMESH C++ API

also, ALL proprietary formats employed in DXS are ZIP-compliant, and can be freely edited (and even created) even by those who don´t have the DXSTUDIO package installed


another option, is that DXS can be embedded in another app as a COM component, which make it a great option to use as a powerful rendering and scripting engine while tucked inside a larger platform (like the current Orbiter engine)


usage of DXS is royalty-free, so only one license is required... which should go for about 100GBP, since orbiter is non-commercial - there is also a freeware license, but it´s a tad limited....

being a beta-tester myself, i can pretty much guarantee that in one way or another, Orbiter could be successfully ported over to DXS

yet a suggest we wait a bit... V4 is coming soon with shader model 3 support and a million other goodies


DXS has already been used successfuly for large-scale simulations, so it´s definitely worth checking out: www.dxstudio.com




--
second choice: IrrLicht3d - an open-source C++ 3d engine, very powerful and unbelievably fast... i haven´t yet had much experience with it, but i see it can be a very powerful tool in the right hands... it supports pretty much all popular mesh formats and has a plug-in library for sounds...

it also has a built-in raycasting system, although not as worry-free as the one in DXS

IrrLicht is free and open source.... i don´t know how well it would suit something in the likes of Orbiter, as most of the demos seem to feature dungeons and that type of stuff...

 

[Urwumpe]

second choice: IrrLicht3d - an open-source C++ 3d engine, very powerful and unbelievably fast...

It's only Irrlicht. I use it myself, it is pretty good, but not automatically an improvement for Orbiter.

I recommend you to really use the engines before you recommend them, it sounds a lot like you just took the information from the homepage.

Irrlicht for example has no raycasting. It supports radiosity maps, which you can generate with a closely related tool, IrrEdit.

 

[Moach]

i actually have Irrlicht here... i did some browsing on its documentation and i remember it did have some form of raycaster, or at least collision checker (different versions, maybe?)

i don´t have any practical experience with it, but i did more than just "check the homepage" for sure...



as for DXS, i have a couple of years of experience with it, so i can say with some more certainty that it could, indeed be a viable option... i actually do own a license for it, so in perhaps a more civilized day (when i get some time in my hands) i could help in looking into adapting a C++ API for orbiter using the new SDK

as i finish my graduation in game design, perhaps i could even integrate this somehow into my plans for my master´s thesis, which would be about community-developed games (like Orbiter), but that won´t be up until the next semester, so we got some good ground-time before that´s even thinkable....


but i can´t help it... my mind races ahead of me... :banana:

 

[Urwumpe]

Yes, Irrlicht has a ray intersection test class inside it, I mistook ray casting with dynamic light mapping, a simplified kind of ray tracing.

i don´t have any practical experience with it, but i did more than just "check the homepage" for sure...

It is still a difference if you just download it and read the documentation, or if you actually tried programming applications with it. Which you can do great with Irrlicht, it has a good integration in other applications, you could maybe even use it for rendering to Orbiter MFDs.

But still, it is not that easy writing an Orbiter renderer with it, you can for example not use many optimizations and tools of Irrlicht, if you want to do more than the typical FPS.

as for DXS, i have a couple of years of experience with it,...

I don't, which is why I can't comment on it. I still think depending on the engine of a single manufacturer is a stupid idea if you want to keep the project alive. Currently, we could even theoretically write a new Orbiter core, if needed, thanks to the open (almost academic) approach despite being closed source.

Still, don't underestimate the challenge: You need to render spacecraft and VCs nearby at the same time as planets in the background. Without some messing inside the internals, this is impossible. A simple 32 bit Z-Buffer would quickly make errors if you have a few hundred thousand kilometer between far and near plane.