[chief1983]

Then try Pastebin.  http://fsscp.pastebin.com/

[Kiloku]

Pastebin it is, then
http://fsscp.pastebin.com/m1a271606

[FUBAR-BDHR]

I've seen that same error quite a few times but only in multi. 

[e1]

@The E

I agree, however... till somebody picks up the huge task of writing a new rendering engine, the graphical development of FS2 will stagnate.

For projects like SoL and Diaspora, a new rendering engine will probably be ready too late to be used in the release. (At least in the initial one.)


At least we already got normal maps for all our models, so in the end, the content can be used regardless of the rendering engine.

(forgive the old quote, but it was on the first page..)

Well, the folks at opensource Vegastrike (space sim along the lines of x3) are in the process of replacing their obsolete engine with one based on Ogre3d.

Given that their requirements will be essentially the same and SCP is short of developer time, would it save effort to borrow some of their effort? (..or have joint development in a space sim engine).

Also it seems after the Ogre3d port they are considering *seamless planetary/space flight* , based on procedural techniques developed for the Ogre3d engine as part ofthis project.

It goes without saying procedurally generated space cities/planets would make immersion incredible, so moving to Ogre3d or looking into integration with Vegastrike code might be interesting ..

[Commander Zane]

You're so going to get bashed for saying that.

[chief1983]

Well I don't know why he'd get bashed for such a first post, but I don't think it's likely to happen.  Code from FSO could not be utilized by Vegastrike, although now that Ogre is MIT licensed we could borrow code from it for FSO.

[Commander Zane]

Because mentioning changing the game code is like mentioning the nice little three-character word that starts with a letter and ends with a number, and is looked upon as heresy for saying.

[The E]

Actually, I don't think so. Suggestions like that, even if they turn out to be impractical, are never a bad thing.

[Commander Zane]

Eh...there's a few topics I've seen that had a lot of complaints about everything becoming incompatable, taking far too long, all progress made in the source becoming moot, I'll have to look around to find these again.

[chief1983]

Still it doesn't hurt to ask.  At least if you have some of those reasons you can then crush their spirits, but don't just assume that's going to happen

Also, he didn't say it would 'be easy'.  So that's cool too.

[e1]

I see, I only found out about SCP via a demo of 'BTRL' a little while ago, so took the fs2_open to mean LGPL or similar and the E's comment to mean an entire rendering engine rewrite being considered, my bad for not reading further..

Less wildly impractically, would it be too much a change of current architecture to add detail to textures at very close range to make them non-bland, (hacked into the first post-processing pass maybe)?
Detail can be procedurally generated by using fractal algorithms (or psuedo-random number sequences based on shift registers if the detail needs to be reproduceable). Detailing algorithms of various types depicting wear and tear/battle scarring/micro-details can be chosen by the artists at different locations (procedural deformation of mesh/normal map would involve far more coding in the form of adding geometry shaders etc I guess).. This might help reduce the use of supermassive textures too..

[chief1983]

Now that sounds like a pretty sweet idea, and there's a lot of large ships with seemingly random details that could probably benefit from that.

[Hery]

Detail can be procedurally generated by using fractal algorithms (or psuedo-random number sequences based on shift registers if the detail needs to be reproduceable).

Could you point me to any publications on this prodecurally generated details?

Anyway, to get back on topic (for developers, though): I've almost finished adding doxygen-style to my post-processsing code, generated documentation is available here: http://quarnos.org/dl/scp_docs/html/namespaceopengl.html

[Nighteyes]

I don't know if this was reported already, but I get a bug:
whenever I die the bloom is turned off and a single frame is "stuck" of the post process image leftover... its kind of hard to explain... if you don't know what I'm talking about I'll add an image...

[Hery]

That problem was already reported and I'm working on it.

[e1]

Could you point me to any publications on this prodecurally generated details?

I am not at all a coder so unfortunately not familiar with publications.. (most of what passes for coding I have done has been in Matlab in unrelated areas to game design at that though I can read c/have done some little algorithm design in it) But I have heard of such techniques mentioned in various places..
I can do some searching online and see what I come across if you wish..


I am not familiar with fractals (other than having encountered cantor sets) but their key propety is self-similarity.
This is useful for creation of maps for various things (eg. cap-ship surface structures)
But mainly I mentioned it as it is used a lot in cloud generation (eg. in adding dirtiness to detail textures).

Pseudo-number generation is an algorithm I was thinking about so same detail is seen by everyone everytime.
Linear Feedback Shift Registers have the following properties:
1. Consist of a register of length N bits.
2. Starting from a seed register state, at each iteration, a new state of N bits are created.
3. The shift register will step through 2^N-1 possible states in a *repeatable* but highly varying way [browseable bitsream].
4. A lot of different shift registers by specifying simple transition logic.


This allows creation of a vast stream of a browseable bitsream with a given seed.
* Initial seed determined for each object.
* Bitsteam divided into blocks of randomness.
* Most computational cost in browsing bitsteam. Bookmarking of bitsream would help I imagine. Also utilising other cpu-cores.
* Source of repeatable randomness for algorithm parameters.
* orient/resize/place premodelled cap-ship surface detail, wear and tear/realtime scarring.

Perlin noise functions are also used a lot, if I recall, and iare the result of combining simple functions with details at different scales, similar to fractals but with a optional self-similarity.

So this is possible.. no doubt there are infinitely more elegant algorithms specifically designed for this type of thing though, I'll see what I can locate and post..

(as an aside, interestingly, this behemoth (200 billion star systems , or so they say) of an engine looks as if it will probably eventually change the way content creation is done, in a few years time).

[e1]

There is a lot of information/books on procedural techniques, it seems..
Some googling gives:

Generation using fractals:

Cloud maps which can be used to create dirtiness in textures such as visible here.Fate of the Galaxy screens.

Public code, links and overviews - the generation mechanism can be fed random data/simplified

Paper on real time rendering

Simple midpoint/Diamond square method to generate a field of scalar values..
Suitable for dirtiness in textures or height maps in asteroids.

Opengl procedural textures webpage
These techiques makes it easy to interpolate as observer gets closer.


Perlin noise

Explanation and algorithm details
Another with code..

Code example in opengl of perlin noise

Opengl procedural textures webpage


Procedural techniques
Survey of procedural techniques that covers many topics

I imagine geometric detailing of gigantic ships will be similar to that of cities, with a few primitives created by moddlers being used in different permutations, in lieu of the buildings in the papers, according to algorithms selected/tweaked. A lot of coding..
Real time procedural cities.

Papers on multi-resolution subdivision modelling The first paper on procedural synthesis gives examples of a Perlin noise asteroid and ways for localised damage deformation visible at close range..


Probably only the texture detailing can be coded reasonably quickly..


Edit - it just occured to me the Ogre3d thread would have a lot of links..

Huge amount of papers on real-time techniques

Also the procedural generation code for planets is on zlib license so some sections could be reused..

[Hery]

Thanks, that looks very interesting. I have many other things on my todo list, but I will also find some time for playing with this.

[chief1983]

This all looks great (thanks for the FotG plug too!), but all I can suggest is don't expect too quick a turnaround on anything like this.  Lots of good ideas get mentioned around here and if they're big they tend to get lost in the fray.  But since Hery is already working on similar stuff hopefully some of these ideas see the light of day eventually

[e1]

Indeed, usually major updates to parts of open source projects like blender even with a huge amount of developers takes years to implement, so games tend to take a decade or so to reach 1.x..

The only part which is even contemplatable would be the texture detailing (either as an fractal interpolation of low res detail or placing dirtiness from a map). As far as i can see from the FoTG screens the textures are mostly very simple, with the dirtiness depicted like that necessitating much of the texture size bloat (even better if it was a cap ship).

Probably there should be a directory in the wiki for ideas sorted by topic area?..