Vega Strike Forums

well, we have to discuss that first, whether and how the ogre version will be used. to start a modified new version i'll use the original vegastrike code, first, in order to make as least modifications to the original code as possible.

wb strook, haven't heard from you for a while =)

well as you should know, i'm working on an implementation of the flight, but shouldn't we leave vs opengl engine as it is?

as you should know, as far as i know now, we needed a full new implementation if we take ghouls version.

Since the vegastrike codebase is not enjoyable for me to work with (python + large and messy) i'll continue my experiment without it, focusing only on data, and since recently also network protocol instead.

well, we have to discuss that first, whether and how the ogre version will be used. to start a modified new version i'll use the original vegastrike code, first, in order to make as least modifications to the original code as possible.

My experiment is just that, an experiment.
I haven't continuously worked on it, so chances that it'll really reach a complete and playable state are slim, it'll prolly have more than one semi-permanent hiatus in the future, and i doubt it is of interest to the vegastrike dev team as a real codebase due to lua and incompatibility with python scripts and other stuff, especially from mods.

What i hope for it to become is just a proof of concept for some thinge like mouse-interface, better trading gui, different travel than spec, fundamentally different system/universe maps, and other gui things that i have in mind and wouldn't be able to realize in the current vs easily.

And since recently also providing a simple server for people to test online multiplayer with the main vegastrike client, since there currently is no functional one available afaik.

For the future of vegastrike itself, if you don't like the idea of a radical rewrite from scratch, you should focus on porting the existing vegastrike codebase to ogre and keep python as a scripting language.

Using both ogre rendering as well as the old vegastrike rendering in the same program seems like a bad idea to me, but use whatever works best for you i guess.

I think someone brought up that ogre doesn't handle the large scale space side very well. Except for the larger celestial bodies and jump points i Don't think we should deal with anything outside the radar radius. That would probably help with some issues.

That's not an ogre specific problem, it happens with other render engines and raw opengl too.
The problem for large distances as in vega is that float positions having limited precision,
they can represent large distances or fine details near zero, but not fine details far away from zero.
Also the zbuffer used during rendering has a similar problem mixing far and details.
It can be fixed by remapping scene hierarchy appropriately as the cam moves for smaller relative float positions allowing more detailed geometry without problems,
and for zbuffer limits rendering the scene in multiple layers, e.g.
a) far planets,
b) nearby ships + stations
c) own ship + 3d cockpit stuff.
Vegastrike's 3d engine does that too afaik. And i have it in my experiment too, might need a bit more tweaking for a few special situations, but works well so far.

hmm ok i'll use the ogre engine for all planets.

well i'm a bit stuck in the moment, i don't know how to synchronize the position of both engines correctly in order to take the vertex data from the ogre engine and place it over the surface of the opengl engine.

i think a three-way data extraction is needed:
1.: convert the pos of world opengl space to planetlocal ogre space and feed the ogre engine with it
2.: render the ogre vertex data
3.: convert the ogre vertex data to opengl vertex data and display it.

pheonixstorm wrote:Except for the larger celestial bodies and jump points i Don't think we should deal with anything outside the radar radius. That would probably help with some issues.

From a player's point of view:
One thing I enjoyed about Oolite was approaching battles and seeing weapons fired and explosions before any ships were in radar range. Basically, it was just enough to figure something was going on, but ships were distant enough that they were not visible at all. So I would suggest a "viewable range" of some sort, or can some sort of culling not automatically remove objects too small to be seen? (I know little about game development.)

(Just some thoughts from a player's point of view)

ghoulsblade2 wrote:Since the vegastrike codebase is not enjoyable for me to work with (python + large and messy) i'll continue my experiment without it

It seems to me that a codebase overhaul or rewrite could have a significant positive effect on the vitality of the VegaStrike community. With OGRE involved, hopefully a large part of maintenance could be offloaded and more focus could be placed on game behavior and exciting new ideas like better dynamism in universal economy, factions, and player interface.

Using both ogre rendering as well as the old vegastrike rendering in the same program seems like a bad idea to me, but use whatever works best for you i guess.

strook, your work on VegaStrike is great, but adding an engine just seems to make a messy codebase worse.

ghoulsblade2, the videos you posted look very interesting! It would be great to see more. I have used Python a bit but not Lua, so I don't like to see Python go away, but if Lua is better for the job, then let's have it!

I think his choice of lua was more of which he likes better and not from a which is better point of view. If you think about it.. EVE Online uses a lot of python for client and server. WoW uses a lot of LUA for the client (not sure about the server). Also know that several other games (notably SimCity 4) use lua as well. As far as seeing a far off battle. Most of the radars that ive seen have a range of 180k km I think. I don't think you would be able to see that far off even with supermans eyes

As far as the codebase.. yeah it needs a good cleaning and I hope that we get some more people working on the code so we can actually clean it up a bit, but for now its going to sadly remain messy. Luckily strook and ghoulsblade are working on seperate forks of VS and will hopefully bring in some fresh code we can use for all versions of VS

By "messy code" what do you mean exactly? If it does not entail re-engineering important code I may be able to help out with some code cleanup here and there. I am not familiar yet with the VS code but have been sloooowly finding the time to look around the SVN sources.
I have lately found my day job doing little to scratch my C coding itch so am interested in getting my hands dirty in something interesting. And maybe in time I could be of more use than simple cleanup work.

The code needs a lot of refactoring and general housekeeping to make it easier to read and understand. Not really much in the way of comments in it and what few it has normally don't explain much or make much sense. Best place to start might be the AI section.

Ah I see. Will see what I can do on that front. Code file changes submitted through Klauss currently?

klauss or myself, just zip and attach a diff and/or the actual files you change. Keep up some good work and dont break anything and one of us might just add ya on for svn access.

Hi guys. Nice to see some activity here.

I've been playing a bit with replacing vegastrike planets by ogre code. Using "mission/modelview.mission" for testing I start a few light-seconds from the planet "Landing Paradise". My problem with this planet is that it is huge. It has a radius of 1.28E9 if I read the dimensions correctly. This is almost twice as large as the sun 6.99E8! For me it looks clearly like a star.

And then there is a star 2 light-minutes away with a radius of 7.46E8. So we actually have a binary system here?

Are there eventually some docs rationalizing the sizes of planets and stars in vegastrike?

afaik it's supposed to be 1/10 of real-life sizes and distances =)

Turned out modelview.mission is using a modelview system which is broken. The game sectors look sane. Btw in-game sizes are in meters.

More pics: http://imageshack.us/g/829/93718274.jpg/


This is vanilla VegaStrike + Ogre3D/OgrePlanet(https://bitbucket.org/lingfors/ogreplanet). It is still pretty much a hack/proof of concept. Planet setup non-existent, planet movement jerky when getting close(simulation atom?), surface renderer needs tuning(fractal algorithm and LOD parameters)....

nice, is the ship rendered in ogre too ? i guess you got the ship shaders to run then, good job =)

oooohhhhhh *drool* pretty

that looks damn good. any chance of a alpha realease with the ogre engine? just so we can play around with this?

@log0 Do you have svn access over at the vegaogre project?

I have access to vegaogre. But this implementation doesn't share any code with it. It is vegastrike with some hooks in the planet rendering code to draw planets of a certain radius with ogre. Actually it only draws/replaces a single planet right now. But the code shows that it works and should make it possible to migrate to ogre incrementally. The vegastrike shaders can be reused as they are. One "only" has to write the materials(klauss?) and a mesh loader(I think strook had some code for this?).

Should I simply overwrite the vegaogre code or upload a patch?

hi log0
nice pic!

well i have had an converter func from vs to ogre i think.

but only for the verticesetc, not for the mapping.

big planet: maybe your problem is z-fighting or that the algorythm needs procedural generation of terrain.

i. dunno how you did it,but in my implementation was it rather mapping a bitmap like bump mapping on and on.

but only for the verticesetc, not for the mapping.

I see. But ghoulsblade2 should have a working one?

big planet: maybe your problem is z-fighting or that the algorythm needs procedural generation of terrain.

Nope. The code to identify(there is this everything is a unit nonsense) a planet assumed a certain radius range, there is no planet setup code yet.

dunno how you did it

Let ogre draw the planets using vegastrike camera(view frustum), then let vegastrike draw the rest(OpenGL doesn't care who is issuing the draw calls).

after a glance on your code, it showed an ogre only standalone application to me. with hlsl and cg shaders.

how do you want to integrate it in vs? is there another implementation?

as you should know, uses vs only opengl shaders.

maybe we should go on with my implementation or integrate yours in mine somehow.

we had done already an overlay mode, in vs with ogre.

my intention was it to switch ogre on when entering the atmosphere.

or was it that your implementation on vsogre showed complete ogre integration in vegastrike?

you wrote, the opengl calls, generated by ogre are compatible with vegastrikes opengl calls...

and what about the position?

also i had problems with different opengl implementations, cause they used glew.h and glext.h....

well i'll take a look on your implementation of the patch, you wrote earlier...

maybe we can work together...

hmmm i couldn't find any new alterations in your vs patched code except this one:
this enables painting the enabled ogre window inside the vs window below the cockpit items.

plz write, if you have a running version (you mentioned you have an version running on vanilla vs)

but note my modifications came mainly from macosx compiling. it would be easy to compile it on osx, then.

also i have those ogre/vs mods that let you make an overlay wnd.