Vega Strike Forums

gotcha!





with your trunk it works now.

uploaded CMakeLists.txt, so one can generate Project files correctly.

we have to discuss how we handle it with the additions to the trunk.

i want to add my additions for displaying planets in the vs campaign without starting uc.

can you tell me how you modified the mission file for it?

ah i see. changed the radius from "1282000" to "5310". this is shrinking by factor 241,43126177.

also, we had to shrink all planets by factor 250 ?

on what platform did you test the flight?

i'll test it on my i5 quad core... lets see how fast it is...

maybe we have to shrink all planets first before we have implemented a more complicatd seamless flight solution.

plz have a look here http://yass-engine.de/downloads/thesis.zip

with this we can simulate real sized planets.

well.. mine is crashing to, when going into the lower LOD levels, after coming very slow.

ah i see. changed the radius from "1282000" to "5310". this is shrinking by factor 241,43126177.

also, we had to shrink all planets by factor 250 ?

on what platform did you test the flight?

i'll test it on my i5 quad core... lets see how fast it is...

maybe we have to shrink all planets first before we have implemented a more complicatd seamless flight solution.

plz have a look here http://yass-engine.de/downloads/thesis.zip

with this we can simulate real sized planets.

Look here: http://forums.vega-strike.org/viewtopic ... 25#p126146

I've changed the radius because it had a completely ridiculous value of 1.28 million kilometers. This is not real sized.

OgrePlanet is Anders Lingfors work not mine. I piked it because it is the most promising planet renderer for ogre imho, although incomplete.

No I do not plan to implement a new planet renderer from scratch(http://yass-engine.de/downloads/thesis.zip contains no source code).

The crashing is new, wasn't there before. I am looking into it.

i implemented multiple planet creation, but it is still buggy.

maybe you take a look into it in /branches/strook/vs_log0

changed:
branches/strook/vs_log0/src/cmd/planet.cpp
branches/strook/vs_log0/src/planet/OPPlanet.cpp
branches/strook/vs_log0/src/planet/OPPlanet.h
branches/strook/vs_log0/src/vsogre.cpp

maybe you take a look into it in /branches/strook/vs_log0

Why don't you checkout http://vegaogre.svn.sourceforge.net/vie ... rike_log0/ apply your local changes and post a patch. Having to jump from one branch to another and diffing the files is not that effective.

If you want source for seamless to look at try Pioneer or Simerge Both have source releases and look decent though still in an early life cycle.

i'm updating it... i'll use Ogre::Real = double precision.

we should use this i think vegastrike uses double precision, too (i'm not shure)

just change OGRE_DOUBLE_PRECISION in OgreConfig.h to 1 and recompile ogre.

i'll implement a variable length test, if neccessary.

ok, here is the patch.

it includes also a modification in CMakeLists.txt that is needed by the Planetrenderer. i dunno why it compiled on the old platform (i updated ubuntu to 10.10).

it is a patch derived from log0 version 247 in the trunk.

the planets won't be rendered by the planetengine , i don't know were the error is in the moment.

Thanks strook, will check it.

we should use ogre at double precision cause we need the large values.

i'll write an addon that ensures this.

also there is a new branch in /branches/strook/mine_vs_log0.

it is my development branch derived from revision 247.

i added basic multiple planet support to the trunk, which is not enabled cause of a bug at generating the planets: if we put a unique name to the materials, the procedural generation will no longer generated.

you must compile ogre with double precision to compile this.

@pheonixstorm: i think we got a pretty good algorytm, which is slow cause it is not parallel programmed and not optimized.

also we can make it faster if we use the optimisations and techniques shown in the thesis from the downloads section in the yass page.

this is how a good seamless rendering algorytm should look like.

atlantis will now be procedurally displayed.

other planets follow.

Good work strook. A few rematks from my side.

The Impl was actually a Pimpl to hide the implementation details and especially ogre headers from vegastrike code. Here more info: http://www.gamedev.net/page/resources/_ ... impl-r1794

I would prefer to keep it private and access it through a abstract interface(CreatePlanet, UpdatePlanet, ...) if possible.

Do we really have to switch to doubles already? Vegastrike worked without them and OpenGL is restricted to floats anyway. It would also complicate the build process. Afaik no linux distribution I know of is offering Ogre with double support.

i am assuming when ogre is working, and we have seamless flight, we will be able to model planets in a lot more detail, even down to terrain contours and adding buildings? Any idea what type of files we would need to model the planets/objects? what format things need to be in?

Thing is, we don't need ogre to be able to do that. We need to make seamless work with VS and VSOgre, especially if we want to have both games connecting and running in multiplayer. The work being done on this is wonderful though. Maybe one of these days I can split this thread up into multiple topics since this IS the VS Ogre forum

I've pushed a fix for the crashing on surface approach(silly bug introduced by me while fixing compilation on linux). To be honest now having had a closer look into the patch code I think it is overly complicated for the job it is doing. I'd tend to simplify/rewrite it.

@Hicks:
I see no problems adding this features. But it is way too early to even think about it imho.I'd prefer to move the remaining vegastrike graphics implementation to ogre after having the planets working before adding more new features.

Btw ogre is just a graphics engine, although a fancy one. It is a high level wrapper of all the stuff needed to be done to draw things on screen. Vegastrike for example is missing such an abstraction, doing it the hard low level way.

I've had some time for testing. The jerky motion while approaching "Landing Paradise" is a precision issue. We are subtracting two large numbers(3E10) close to each other (planet position - camera position) which causes serious issues when getting close to the surface(50km).

OK. It is not the subtraction. The camera position jumps by a value of 2048m every few seconds on x and z axes . Given the messy code I am not sure if I'll be able to figure out why.

Position issue resolved Will start to refactor planet code to properly support multiple planets.

Hey guys. I've been wondering how much of the planet configuration should be exposed. The height data source is modular and rather flexible.

Current configuration(I've collapsed scale, scalebias modules to simplify it): The select module blends source1 and source2 based on the control and falloff value(falloff = 0 no blending).

OK this one took a bit longer than anticipated. The planet code support multiple instances now. Currently it will replace all planets(stars) in the system, the only parameter atm is planet radius.

Todo:
Camera setup. Light source setup. Working on planet lod(quite visible lod switches). Performance optimizations(we are vertex heavy 30k-170k). More planet parameters, replace current simplistic shader with the complex one.

Features:
It is multi-threaded and will require multiple(2) cores to run smoothly. The implementation requires shader support. I don't think there is a way to avoid this, we will need linear z depth. The integration into vegastrike source requires changing about a dozen lines of code in three files. I think it can be merged into vs and run conditionally if desired.

@pheonixstorm what would be your minimum requirements to consider the code to be ready for inclusion?

Btw would be great if someone else tried to build/run it, not sure if strook is still around.

Get it ready and I will add it to my branch. I can compile for linux and windows. Will probably have to add in a setup config so that those with low end cpus can opt out and use the normal routines. If you think its ready i'll add it to my branch. We can work out all the bugs as we go. I really want to see how this looks in VS proper

Cool. I'll add camera, light source interface and create a patch against your branch.