Roadmap 2013

[binstream]

Render

 

• Edge blending - Q1 - done

• Distortion correction (non-linear image mapping) - Q1 - done

• OpenGL render migration to the Core profile - Q1 - done

• Anti-aliasing for Mac OS X - Q1 - done

• Increased rendering FPS stability - Q1 - done

• Improved GPU detection - Q1 - done

• Improved decal projection accuracy and performance - Q2 - done

• Spline-based road system - Q2 - implemented mesh-based system

• Rivers simulation system - Q2 - postponed

• Morphing mesh - Q2 - postponed

• Vertex coloring support - Q2 - postponed

• Infra-red post-process - Q4 - postponed

 

World management

 

• Improved resource streaming for huge worlds - Q1 - done

• Improved zone-based streaming - Q1 - done

• NodePivot for transformations - Q1 - done

• Seamless multiple terrains - Q3 - done

 

Framework

 

• Extended C++ API - Q2 - done

• GIS data formats support - Q3 - partially done

• Geospatial data support - Q3 - done

 

Network

 

• CIGI protocol support - Q2 - done

• DIS/HAL protocol support - Q3 - postponed

 

GUI

 

• Flash improvements - Q4 - done

• High-level GUI scripts library - Q4 - postponed

 

Tools

 

• FBX import plugin - Q1 - done

• OpenFlight import plugin - Q1 - done

• Easy deployment to mobiles with editor plugins - Q3 - postponed

[demostenes]

When we can expect asset browser with some drag and drop functionality? We already converted over 1300 of our assets into Unigine (still few thousands to go), so finally world building will continue very soon.

 

This is actually major flaw, some of my artists already claimed, that without it they will not work and quit the job. And I really cant blame them, it is NOT possible to work without knowing, what you have in the library and you really cant have in head several thousands models and what is where and what is its name. Or shouldnt we wait and try to develop it ourselves?

 

Are you considering FBX import even with some auto creation/assigning of material (such process can be done, check for example Unity)? This is huge flaw of import process, you have to do it manually, or create some scripts and it still takes literally 100x more time then it should. We were importing 1300 assets cca 3 months(!!!) even with some custom scripts support. Lots of wasted mandays = huge costs.

[ulf.schroeter]

 

Framework

• GIS data formats support - Q3
• Geo data support - Q3

Network

• CIGI protocol support - Q2

• DIS/HAL protocol support - Q3

Tools

• OpenFlight import plugin - Q1

 

Hi Denis, these roadmap items indicate a clear focus on the simulation area and serious gaming applications. In general I belive it is a very good idea to address these high-end customers and to separate UNIGINE engine from other main stream engines, but nevertheless just a personal warning based on several years of programming experience exactly in these areas:

 

DO NOT focus on above mentioned interface / data formats as you will simply get lost in the diversity and complexity without a real benefit for the UNIGINE engine itself ! I should put 10 more exclamation marks here to visualize that I am really yelling this friendly warning to you...

 

Be sure that you can easily waste multiple man years of development efforts on these issues without being able to deliver a usable solution for - nearly always - very specific customer requirements in this area (most of the time combined with all kinds of historic application restrictions / workaround, etc)

 

Instead

 

• provide a full-fledged C++ interface so serious game customers can integrate UNIGINE directly into their existing C/C++ simulation frameworks and can access ALL engine functionality without being forced to use scripting bottleneck
• provide a very easy way for UNIGINE content import/creation of static/skinned/morphed meshes and terrain data e.g. based on simple XML format in addition to the existing binary formats. This will allow customers to transform their specific data formats / assets (e.g. in complicated OpenFlight format) using their existing data generation pipeline to UNIGINE quite easily on their own.

Feel free to get in contact for an in-depth discussion on each of the above topics.

[binstream]

demostenes

 

We are working on improving assets pipeline as well.

 

FBX import with materials support is already implemented, will be available in the next SDK.

[binstream]

Ulf, thank you for the warning - we are still discussing internally the best way to provide support for this formats/protocols.

They are anyway not the main focus because we already aware of their diversity. May be the solution will be to simply use GDAL/OGR format aggregators.

[demostenes]

demostenes

 

We are working on improving assets pipeline as well.

 

FBX import with materials support is already implemented, will be available in the next SDK.

 

Thanks. And asset browser?

[ulf.schroeter]

Ulf, thank you for the warning - we are still discussing internally the best way to provide support for this formats/protocols.

They are anyway not the main focus because we already aware of their diversity. May be the solution will be to simply use GDAL/OGR format aggregators.

 

I would even leave this part to the user and concentrate on the core engine (especially streaming) and above mentioned items for simplifying general engine integration into exiting programming and data generation environments  

[demostenes]

I would even leave this part to the user and concentrate on the core engine (especially streaming) and above mentioned items for simplifying general engine integration into exiting programming and data generation environments  

 

Absolutely agreed. Btw, we are now integrating 3rd party networking solution and there is lots of space for improvement....From my point of view it really makes sense to focuse on features like streaming, speed of vegetation rendering, effectivnes on GUI and flexibility of API and throwing away support of DX9 ;)

[steve.brodie]

I partially agree with Ulf that GIS and Geodata is a rabbit hole with no end.  However, I think that if Unigine just picked one or 2 formats that were widely compatible and set a standard for their import requirements, it would then not be such a big deal.  Users could do the conversions to the required formats in 3rd party tools.

 

Maybe choosing a number of georeferenced formats for dtms, imagery and vectors is all that is required.  For example:

- Imagery tiles - geotiffs or ecw

- Elevation data - geotiffs, or a non image based format that doesnt require vertical scaling, such as BT (Binary terrain) or similar USGS DEM (http://vterrain.org/Elevation/)

- Vector - shp shape files.

[ulf.schroeter]

Steve, even with such a minimalistic approach trouble is already on its way: For all geo data types: how to deal with spherical coord systems, how to handle different geo-reference-frames, how to handle geo attributes, how to handle robustly the divers different variation/subformats within each format, ..., ... just thinking one second on the very basic ESRI vector shape format: sure, its is some kind of a standad, but how to handle point and line shapes ? For polygonal shapes with holes etc. you already need water-tight polygon tesselation for UNIGINE mesh conversion...how to handle input coordinates provided in double precision as they have to be converted to float mesh vertices, how to assign texture and texture coordinates, ..., ...

 

Just my personal feeling: DONT DO IT  :)     

[binstream]

OpenFlight format support is already implemented, will be available in the next SDK update.

[ulf.schroeter]

OpenFlight format support is already implemented, will be available in the next SDK update.

 

Sounds interesting. Looking forward for some insight on next SDK release how the importer handles things like switch, transform, material nodes or sub-node-trees referenced from multiple parent nodes.   

[steve.brodie]

I think for a lot of simulation users, its getting real world terrain height data and satellite imagery into Unigine, that is more important than shp files.  Really, the only thing thing making the task of getting real world data into unigine at the moment is the lack of a decent gridded DTM elevation format, for real world data.  The current grayscale formats either lack 16bit support or need scaling operations to make them work.   How about support for BT Binary Terrain format, there are some example datasets here. http://vterrain.org/BT/

[frustum]

Sounds interesting. Looking forward for some insight on next SDK release how the importer handles things like switch, transform, material nodes or sub-node-trees referenced from multiple parent nodes.   

Its really difficult to find a propriate content to check the functionality.

So several modern features like meshes and extended materials are not implemented.

[frustum]

Can anyone share OpenFlight models so we can test all functionality?

[frustum]

Steve, even with such a minimalistic approach trouble is already on its way: For all geo data types: how to deal with spherical coord systems, how to handle different geo-reference-frames, how to handle geo attributes, how to handle robustly the divers different variation/subformats within each format, ..., ... just thinking one second on the very basic ESRI vector shape format: sure, its is some kind of a standad, but how to handle point and line shapes ? For polygonal shapes with holes etc. you already need water-tight polygon tesselation for UNIGINE mesh conversion...how to handle input coordinates provided in double precision as they have to be converted to float mesh vertices, how to assign texture and texture coordinates, ..., ...

 

Just my personal feeling: DONT DO IT  :)     

We will support GDAL based height map import for terrain only.

[ulf.schroeter]

Can anyone share OpenFlight models so we can test all functionality?

I will have a look at the start of next week if I find some OpenFlight models for testing

[Guest shane.ploenges]

Seamless multiple terrains - Q3

 

 

Currently we use a world system that has many terrain tiles joined together, and our own script to stitch tile edges together to stop visible gaps from appearing.

 

However (as you would expect) using a flatness setting of anything other than zero results in the gaps reappearing.

 

The question is will the terrain system support smooth blending of multiple tile edges (with flatness above zero) in the future?, is there a way to do this currently without the enhancements mentioned in the roadmap?

[manguste]

I will have a look at the start of next week if I find some OpenFlight models for testing

Ulf, that'd be really great if you find some.

[manguste]

Currently we use a world system that has many terrain tiles joined together, and our own script to stitch tile edges together to stop visible gaps from appearing.

 

However (as you would expect) using a flatness setting of anything other than zero results in the gaps reappearing.

 

The question is will the terrain system support smooth blending of multiple tile edges (with flatness above zero) in the future?, is there a way to do this currently without the enhancements mentioned in the roadmap?

 

Shane, we'll pay attention to that when implementing seamless terrains. Right now what we can promise is no gaps, all other details will be clear later.

[anthony.mann]

I have a question about the Rivers simulation system - Q2.  Will this have anything like a fluid dynamics feel to it, where rivers would/could form to follow the terrain? Or something more traditional, like what is found in other game engines where you draw out where you want rivers to be and apply an appropriate shader?

[cory.sharplin]

Looks like a big year ahead, however it is a shame I see no new Debug environment or Visual Studio intellisence on the roadmap.

 

I'd like to reiterate something that has been said by a number of people over the last 2 years.

We need to get something better for debugging UnigineScript. We are wasting far too much time commenting out code or putting in log.messsage to try and isolate bugs.

 

The ability to break and interrogate variable contents, or at least get a line number instead of just a stack trace (like when trying to use a NULL variable) would be greatly appreciated.

 

Or a more sophisticated UNIGINE script debugger GUI as per ulf.schroeter feedback request

 

If anyone has a work around please provide feedback, thanks (ideally we would like to stay in Visual Studio)

[danni.coy]

I have attached the file I use in my IDE to get it to play mostly nice with uniginescript.

All you need is a method of including it in your projects without having it being included at runtime.

With my IDE (KDevelop) this is done with #define IN_IDE_PARSER #endif blocks around the include. Visual Studio should be able to do this somehow. The things that aren't working for me are the language contructs that aren't in C++ foreach, foreachkey and forloop and some difficulties with nested namespaces.

uniginescript.h

[kudrik]

Планируется ли в этом году интегрированный в редактор контент-браузер? В плане не увидел.

Без него работа контентом превращается в кошмар.

in-english:

Do you plan this year integrated into editor content-browser? I don't see this point, on roadmap.
Without it, the work with content becomes a nightmare.

[maimonides]

This is an issue for also for our team.