Question Ultra Low Graphics Client

[Zachstar]

Hello all. Another random topic about OVP.

I was thinking about the first computer I used Orbiter on. An old Compaq with an AMD k-6 core as power hogging as that thing is compared to a modern PC today. It was still quite the machine.

Anyway to get to my point. Obviously it will be difficult at best to run orbiter on it in this day and age. Same goes with many systems that are older but not replaced yet for a variety of reasons.

Many of these systems have one thing in common.. Horrid Microsoft Software version of OpenGL and DirectX so low its not worth mentioning. However many of these systems excelled at software rendering (The type of rendering used in "Shuttle" and non Open GL versions of Quake)

My question.. Is it possible to develop a client that can make use of this effect? A client that assumes your PC is an old PC without GPU acceleration?

 

[Artlav]

Like that?

Seriously, it might be an interesting thing to do.
Efficient software rendering is once again a black art this days, but something like a simple wireframe visualization can be done relatively easily.
What about vessel meshes? Some way to reduce polycount to lower hundreds on any mesh is mandatory.
A think like that MUST be developed on an ancient computer, or getting performance might be rather difficult.

 

[Urwumpe]

I already joked about making a Orbiter visualization client based on the windows console functions or PDCurses. Didn't know somebody really did it.

Making a software rendered version of Orbiter with 1995 state of the art technology would be impossible without changing the meshes. Gourand Shading and textures existed, but I can't remember more than 256x256 textures used then. Most had 64x64 textures.

 

[cjp]

Making a software rendered version of Orbiter with 1995 state of the art technology would be impossible without changing the meshes. Gourand (sic) Shading and textures existed, but I can't remember more than 256x256 textures used then. Most had 64x64 textures.

Software rendering is faster without Gouraud shading; it's easy to use flat shading instead. Textures can also be down-sampled easily. Mesh optimization is possible, but even the smartest mesh optimization algorithms I know don't make very good low-poly meshes. So you'd have to accept having very ugly meshes (uglier than the ones of old-skool games that run on the same PC).

Besides, there will still be a memory issue, because the application probably still needs to keep a copy of the original mesh in memory, in case the add-on wishes to modify it. Mesh- and texture-modifying add-ons will be unsuitable anyway for such a retro system, because the continuous down-sampling and mesh-optimization would probably add a lot of extra work to the CPU.

It's probably better to keep the system simple. Let the renderer only use some straight-forward tricks to make the system faster (e.g. flat shading, nearest-texel texture filtering, polygon sorting instead of z-buffering, ...), and use external tools to manually optimize mesh files and texture files before starting Orbiter.

 

[Urwumpe]

What about making a "ugly duckling" version of Orbiter by replacing the meshes of the default vehicles by low-poly versions and low-level textures and fix the animations of them?

 

[Artlav]

I started to wonder why do it?
What about a mobile Orbiter version?
WinMobile is Windows, more or less, so porting the core should be less hard than to Linux, and once done this client (TridesClient?) will come in handy.

I think, the aim should be not on the old computers, but on low-end ones and mobile/embedded systems.

No?

---------- Post added at 09:00 PM ---------- Previous post was at 08:55 PM ----------

Then, implementation ideas:
1. Why meshes?
A set of pre-rendered views of a vessel mapped to a polytope/sphere can do the trick.
Docking might be a problem.
A wireframe outlines around ports maybe?

2. Planets?
Should be easy - Lv2-3 textures mapped to a logical sphere. Maybe even a voxel engine for the surface.

3. Panels/MFD's?
Pretty much the same.

4. Controls?
Can be hard - i only know one PDA with a keyboard, and it's a rarity.
Ideas?

 

[Urwumpe]

No, I think we can afford simple meshes, but the 20000 poly recommendation would be out of reach. Maybe we could do 500-1000 polys. Still more than enough - just look at Privateer.

Virtual Cockpit: Impossible, since it requires many graphic resources.
2D cockpit: Quite Possible, maybe even the recommended user interface there.
generic cockpit: Should be the low performance fall back in any case.

2. We could also render like in Damocles... flat circles rendered to flat surfaces after passing entry interface. Could also work with textures to produce the illusion of spherical planets

4. Touch screens would work good with 2D panels, we would then just need a way to map RCS commands to touch positions

 

[Zachstar]

WOW I had half expected to be laughed out of the forum for posting such a topic I am really happy to see serious discussion about it!

I did not detail my thoughts enough tho. Obviously in my view any "addon" or "Mesh" developed would have to use the msh format and be custom made. If one could "force" an existing mesh to load differently that would be awesome but that sounds like more than a K6 could handle.

Porting to Windows CE (Windows Mobile) devices is impossible unless martin ports the core. Those usually run on ARM type cores and they do not have enough power to emulate anything more than simple DOS games. Intel's Atom however is another story but devices that use it are generally larger.

What about if Orbiter were to be able to send out stuff from the core over the net? Perhaps like your other topic but much more simple. Perhaps just enough to saturate a 56k line. Would that not be enough to send details that such a mobile client can use to render a scene? With simple controls it would be enough to do some actions and if some MFD makers cooperate perhaps even be able to control a navigational MFD?

 

[SpaceNut]

Like that?

Seriously, it might be an interesting thing to do.
Efficient software rendering is once again a black art this days, but something like a simple wireframe visualization can be done relatively easily.
What about vessel meshes? Some way to reduce polycount to lower hundreds on any mesh is mandatory.
A think like that MUST be developed on an ancient computer, or getting performance might be rather difficult.

Lol... ASCII Orbiter How cool would that be

 

[Zachstar]

Looks like Artlav routed the image to libcaca tho I heard it was difficult to implement in windows.