Spring RTS Engine

buildings are more or less units, otherwise you may as well say subs, ships and aircraft are also different types.

smoth wrote:buildings are more or less units, otherwise you may as well say subs, ships and aircraft are also different types.

If the base unit is a giant robot then sure, buildings are units, but if the base unit is an infantryman then buildings being terrain would allow units to climb buildings or jump from rooftop to rooftop or for helicopters to land on roofs (though I'm not sure how that game would actually play).

God dude, shut up. We are talking about engine stuff not some BS session about what is blue. There are really 2 things features and units when it comes to rendering and shaders.

smoth wrote:God dude, shut up. We are talking about engine stuff not some BS session about what is blue. There are really 2 things features and units when it comes to rendering and shaders.

... yes, and we are discussing the need for a third.

would allow units to climb buildings or jump from rooftop to rooftop or for helicopters to land on roofs

This is dreaming imo. Having buildings/units be part of the terrain is not realistic - the ground can only have one y co-ord per (x,z).

Silentwings wrote:

would allow units to climb buildings or jump from rooftop to rooftop or for helicopters to land on roofs

This is pie in the sky tbh. Having buildings/units be part of the terrain is not realistic - the ground can only have one y co-ord per (x,z).

I was thinking more along the lines of the upper y of a mesh being used to define the "ground" such that you built your map out of meshes and then the engine treated the "top" of it all as "ground".

That would result in e.g. the area under an overhang or bridge becoming impassable since it was not considered ground. Moreover, the pathfinder would have literally no idea when jumping over gaps was possible. It's unrealistic to expect some magic way to make Springs framework handle "all u want in 3d combat", new map format or no new map format.

You can have several heights on same position, it is called Digital Elevation Model.

http://en.wikipedia.org/wiki/Digital_elevation_model
http://wiki.gis.com/wiki/index.php/Digi ... tion_model

Here are a lot of opensource tools for map representation, just pick up the ideas.
http://www.osgeo.org/
Some libs can do many things https://www.gaia-gis.it/fossil/libspati ... ations-4.0.

I am aware that caves, bridges and so on exist in reality and are within the realm of what modern physics can describe. The issue here is that Spring has an already established (and basically successful) framework under which the terrain has only one y per (x,z). Unless you are offering to do the work involved in changing all that depends on this (its maybe not impossible), knowing that somewhere there is software able to parse 3d models of terrain is not very helpful.

I wasn't thinking to do an Earth-like representation with everything such as caves, buildings. But that if you really want to it's possible and that you can pick up ideas in geographic information systems documentation. Obviously in GIS there are a many ways (and ideas) to represent map data.

Concerning the change of map representation, I think one day or another someone will have to jump in it and do the work, better to have raw materials to know what is best and what is worst.

Why do I think it is needed ?

On Project proposal page, from what I've understood, many are related to a change of internal representation.
I'm not an expert in graphics either, but after looking for documentation and feedbacks on dev forums and research papers, a Kd-tree/AB-Tree/Octree + mesh would be a serious step to:

• Implementing a Scene Graph as they are accelerating structures,
• Sensor handling redesign / simplification by doing a faster LOS, see here, current way is efficient for an heightmap, thought,
• "3D map format" project, see current topic.

Of course that would mean work and to break many things on the way for the courageous one that'll do it. Because he/she will be told "you broke everything" many times.

P.S.: Are the project pages up to date ?

GIS.. mmh.. i looked at those. Satteliteimages for textures are pretty huge. calculating wether a complex geometric area is within a rectangle or not takes ages, depending on algo. They are very precise though, i give you that.

Correct me if i m wrong, but from this only those adapting real landscape would benefit. Disregarding the realism does not equal fun discussion, this would still only benefit a niche audience.

Nearly none of the most played maps are adaptions of real landscape.

If we update the mapping system then we could also get rid of the non-standard convention of denoting y as the vertical axis.

There is no standard convention (not between professional standards, not amongst academics, basically nowhere). But iirc both DX and OpenGL use the y axis for up, by default.

Jools wrote:If we update the mapping system then we could also get rid of the non-standard convention of denoting y as the vertical axis.

Just because blender and Max do that does not make it standard.

Silentwings wrote:There is no standard convention (not between professional standards, not amongst academics, basically nowhere). But iirc both DX and OpenGL use the y axis for up, by default.

^this

Silentwings wrote:There is no standard convention (not between professional standards, not amongst academics, basically nowhere). But iirc both DX and OpenGL use the y axis for up, by default.

that's not entirely true, the right hand rule always applies for any engineering/mathematics use case.

I've always thought that the only reason that y-up in 3d space even exists is because someone didn't quite understand the difference between screen space, world space, object space coordinate transforms.

it doesn't matter, Y has been up for as long as I can remember as far as games and game engines. I only saw it in autocad, max and blender. Spring is not going to flip Z for Y, it isn't happening so why does this have to do with mapping? because blender uses z=up so you guys want that changed?

smoth wrote:because blender uses z=up so you guys want that changed?

IMHO it doesn't matter, I was just stating an opinion. there is no way that spring will change the coordinate system without some substantial gain to be had. and nobody is demonstrating that.

well you and jools are arguing the point. So I am rather curious as to why the argument needs to be made.

I had a bit of a play with 'understand' source analysis ( there is a 15 day trial )
https://scitools.com/

it can show you the dependency graph for source files, and there is a lot depending on the SMF portion of the code.

I think any changes that you would want to make would be a refactor to abstract away (should have always been abstract) the smf code so that nothing depends on it directly anymore. then further changes are at least possible without too much breakage.

The right hand rule always applies for any engineering/mathematics use case.

It doesn't, there is no convention amongst mathematicians - you won't have to look far to find journal articles using both. Maybe there is amongst engineers, I don't know much about that.

But of course it doesn't matter at all and we are already using the most conventional option for our situation; this thread is cluttered with so much rubbish now . Forget ~everything on this page & start again from the bottom of page 1 imo.