Unigine SDK 2011-11-11

[binstream]

Schemer (preview)

 

Schemer is a visual scripting system that allows creation of complex sequences of gameplay events without having to script them manually. This way the artists can add interactivity to the world without the help of a programmer. By connecting paths in a flow graph, it is possible to script cutscenes, switches, timers, changes in lighting and much more.

 

 

Schemer is written in UnigineScript, its files can be found under data/core/systems/schemer folder.

 

Skinner (preview)

 

Skinner is a visual scripting system for animations. It allows blending different animations together to create complex movements of skinned characters. It also possible to include the physical ragdoll into played animation (for the whole the character or per bone).

 

 

The Skinner is based on Unigine::Schemer. Skinner scripts can be found under data/core/systems/skinner folder. The predefined Skinner blocks that are available by default are contained in the data/core/systems/skinner/blocks/skinner.blocks file.

 

 

Both Schemer and Skinner systems are parts of upcoming UnigineEditor 2.0, they can work with internal Unigine GUI and external one (Qt-based).

 

Scratch project

 

A Scratch project will help you get started with your own Unigine-based game in no time. Tweak and play all using the same application: change settings on-the-fly, see the coded behavior in effect or quit the Editor to go into in-game mode and test how your game feels like. No compilation is required: simply add your models, replace the GUI interface and run the launcher.

A Scratch project can be found in UnigineSDK/scratch folder, read more in the documentation. It is available only for Windows and Linux platforms.

 

Render:

• Added AppEyeFinity application for enabling AMD Eyefinity technology (multi-monitor rendering with arbitrary projections for each monitor).
  
• Added NVIDIA FXAA post-processing material (changed implementation of post_filter_antialiasing material).
  
• Decals can set texture coordinates (so it's possible to use texture atlases for them).
  
• Changed texture transformations for billboards: sx,sy,tx,ty instead of old x0,y0-x1,y1.
  
• Increased terrain loading speed.
  
• Fixed wrong number of emitted particles for "spark" emitters.
  
• Fixed alpha-test issue on iOS 5.
  
• Color-fading (can be used as a simple alpha-fading also) instead of decreasing particle count by distance.
  

Work in progress, upcoming Unigine-powered demo:

 

UnigineScript:

• Support of script caching for faster load (cache file name is the second argument of world_load command, no caching by default).
  
• Added "using" keyword for extending current scope to other namespaces.
  
• Support of #if preprocessor instruction.
  
• Added extern class member call by ID (useful for faster callbacks).
  
• Added functions support to Expression.
  
• Added new base functions: is_variable(), set_variable(), get_variable(), is_extern_class_function() and get_extern_class_function().
  
• Removed Expression::runFunction() methods, use call(getFunction()) instead.
  
• Added left() and right() methods for vectors.
  
• Added new constructors for matrices: mat4(quat,vec3) and dmat4(quat,dvec3).
  
• More verbose error messages for extern classes.
  
• Adde npot() (nearest power of two) and udiv() (integer division with rounding up) functions.
  
• Updated function library documentation.
  

GUI:

• Fixed callback processing order on mobile platforms.
  
• Refactored WidgetCanvas.
  
• Added hide/show methods for virtual keyboard on mobile platforms.
  
• Added RELEASED callback.
  
• Wide mask for PRESSED callback of Button and Icon (includes 4 auxiliary buttons).
  
• Fixed TabBox expanding.
  
• Reduced texture fonts (non-TTF ones) to 128 characters (latin only).
  
• Added ImageTTF tool for conversion of TTF font into a texture for FontTexture.
  
• 32 bit TTF symbols for better support of Chineese.
  
• Improved integration with Qt widgets.
  
• Added a set of Unigine::Widget* classes, which can be switched between internal (Unigine widgets) and external (Qt-based) implementations (they can be found in data/core/systems/widgets folder).
  

Physics:

• Added Exclusion masks for collision shapes and PhysicalTrigger.
  
• Fixed inertia tensor calculation bug for small objects.
  
• Fixed sliding of non-physical PlayerActor on slope surfaces.
  
• Particles with "length" emitter are collided as capsules.
  

Other:

• Added FileSystem C++ plugin: it can handle up to 16 external directories (they must be specified by multiple "-file_path PATH" CLI options; they are saved into the engine config after that).
  
• Increased speed of XML parser.
  
• Added support of iOS 5 (no more NEON support due to llvm restrictions).
  
• Added vec3 and vec4 Property types.
  
• Added functions for creation of buffers and files out of streams into C++ API.
  
• Implemented correct yuv2rgb color space tranformation for video playback via Ogg Theora.
  
• Command line parameters and engine config are now accessible via C++ API.
  
• Fixed "HeapChunk"-related crashes.
  
• Fixed bug with saving multi-surface ObjectMeshDynamic into a file.
  
• Correct handling of ;/+-,. symbols on non-English keyboard layout.
  
• New policy for Node ID: old IDs aren't changed, NodeReference contents get random IDs.
  
• Fixed binding clutter objects to parent ones.
  
• Updated documentation on custom GUI skin.
  
• Updated documentation on particle systems.
  
• Added "Tools / Performance Profiler" article.
  

Download links

 

All files can be found in "Downloads" section of the portal: https://developer.un...ileserver/index

[steve3d]

Well the Fxaa shader still based on Fxaa v2? Why not v3?

[ulf.schroeter]

To add another well: what about world zone streaming ? long time awaited, still no schedule/progress at all...

 

I am a big UNIGINE fan for years now, but to be honest, UNIGINE has lost a lot of its initial top-notch pace. There was a high-end pc-focused time (release of tropics/heaven benchmark) when UNIGINE was named as possible CryEngine/Unreal competitor in terms of visual quality. Somehow this has faded...

 

I don't want to offend anyone, UNIGINE team is working very, very hard, but all the energy now seams to 'disappear' in multi-multi-multi low-end platform support, redundant bloat of scripting close to C++ feature level (without even having sophisticated debugging) while full-featured C++ API for high-performance applications not possible with scripting is missing, on-going GUI re-work (flash/Qt), undocumented code samples/game framework/shaders hindering customer adoption, unclear development road-map, ...

 

Just my personal feeling, but somehow UNIGINE has lost a clear focus and is now going into a 'me-too' direction...sorry for these open words, but that's not the direction UNIGINE should go as there are already a dozen of other low-priced engines providing the same - sometimes even more - functionallity.

 

UNIGINE should re-concentrate on its core idea: top-notch graphics quality, performance and render features not available in any other engine

[steve3d]

Err.. Same question. seems unigine's main develop platform is Linux, and also why unigine try to create all things by you self? There is free physx sdk for almost all platform with 32/64bit support, speedtree v6 also support Linux Mac win but still no more progress about a fully intergrate, double precision feature is no more than a toy, without streaming support, this is useless in production. Is that really so important to support those mobile platform, without a full featured pc solution. And there is another problem, nvidia has fully supported multithreaded rendering in dx11, does unigine has plans for that? I did NOT want to complain about unigine, these are just my questions, sorry.

 

I think it's time to show us next year's roadmap, right?

[alexei.garbuzenko]

:lol:

Welcome to the club, Ulf and Steve! :)

there are lots of features that we are waiting for years - updates in separate thread, adequate terrain with 8+ materials, fix of alt-tab in fullscreen and other meaningless crashes, support for speedtree-like 360* billboards, huge worlds, dozens of objects, etc. And I'm not speaking of hundreds of topics ignored in 'Bug reports' forum and 'Suggestions'..

The only thing we can do is hope for the best.. or for a valued customer that will ask developer for such features and expect them to be implemented soon.

[frustum]

The market of 3D engines was changed. We have free UDK, CryEngine and Unity now. Earn moneys by making good looking rendering engine without game component systems, editors and multiple platforms support isn't possible anymore. We don't lose our focus. The target is same: creating stable next-gen platform for games and visualisation purposes.

[ulf.schroeter]

Alexander, I don't want too be to pessimistic, but I don't think that you will be able to overcome resource and/or time advantages of UDK, CryEngine or Unity3d. You should concentrate on features and customers where these engines - and others - do not provide a solution.

 

As discussed for a long time serious gaming and simulation with their special requirements (very large worlds with complex urban/natural environments, dynamic terrain, vast forests, fully dynamic lighting, huge object counts, crowd rendering etc) is still a place where you could earn lots of money just based on visual quality and special features not available even in engines like CryEngine/UDK (double precision is a very good example, but - as stated by steve3d - useless without full-fledged world streaming)

 

Have a look at Bohemia Interactive, who managed to roll up the military simulation market (1.000.000x more money than the indie market...) with their VBS2 engine

 

Just to give you another figure: we licenced another - quite bad - engine for 40x the price we payed for our UNIGINE licence (ask Denis for the actual fee and then start crying...). In addition we pay them customized feature development for special simulation requirements. Actually they get paid for improving their engine based on our special knowledge and these new features also greatly leverage their game related licencing opportunities.

 

Just based on these costs it would have been possible to finance 4-5 UNIGINE developers for years...I am still totally disappointed that we missed this opportunity due to missing feature support

[binstream]

Ulf, you are right. As I wrote before, I'm also worried about changed market and finding focus in this situation.

 

Right now we had to improve tools (and will continue this next year) because they were way too outdated, but we do understand that we ultimately need some new killer features. And yes, simulation market looks appealing for us since I don't believe we can beat pure gaming engines.

 

Our "Valley" project was the first attempt to create large simulation-like world, we get back to it now to add zone-based loading and large vegetation scenario. Alexander is working now on "Tracker" component required for day/night cycle (it will be used in this project as well), streaming improvements go right after this.

 

PS: More detailed roadmap is under heavy internal discussion last month, I hope we'll finalize it in 1-2 weeks, it will be published here.

[binstream]

BTW recently added double precision coordinates support is a part of our strategy moving towards simulators.

 

PS: Unfortunately no one pay us for custom feature development, so we have to work sometimes on some market-dictated stuff like mobile platforms.

[binstream]

One more notice: we are limited by DirectX 9 support a lot, if we could abandon it, there is a non-restricted terrain shading, new materials and SFX, better crowd rendering and so on...

[ulf.schroeter]

BTW recently added double precision coordinates support is a part of our strategy moving towards simulators.

 

Fully understood, and I think it was highly appreciated by all long-term UNIGINE users. But 1) it took a year and a half of steady requests on the forum for getting it and 2) still requires a full-fledged streaming system for all kind of assets for being usefull for customers. And this is for sure non-trivial and it will take a lot of time, even for brilliant frustum, to implement it... but currently time is spent on so many other issues

 

PS: Unfortunately no one pay us for custom feature development, so we have to work sometimes on some market-dictated stuff like mobile platforms.

 

There would have been the opportunity, see my comments above...apart from that I fully understand the difficulties your are facing within challenging game engine market...but that's exactly the reason, why it might be more than ever neccessary to re-think best strategy for staying competitive. Maybe my personal view of market developments might be totally wrong, actually you know much better if e.g. mobile platform support has significantly increased your UNIGINE licensing counts

 

One more notice: we are limited by DirectX 9 support a lot, if we could abandon it, there is a non-restricted terrain shading, new materials and SFX, better crowd rendering and so on...

 

I think this is a perfect example for general strategy decision, same question for ps3/xbox/mobile platform or mac/linux support. DICE did simply drop support for DX9 and fully focused on DX11 for MW3 while having for sure much, much more developing resources (I just saw their huge office in stockholm 2 days ago)

 

Trying to support everything to a limited degree or specialize and fully focus limited resources e.g. on windows 7 DX11-only top-notch solution without all the multi-/redundant-/legacy burdens like in earlier days? Of course no easy decision for any multi-purpose game engine provider...stay mainstream like all others or get special but unique ? I am quite sure that the next 12 month will show, which way has more long-term potential

[danni.coy]

Which platforms which are covered now won't be covered if DX9 is dropped. I was under the impression that for nVidia OpenGL offers more features on XP. (AMD?,Intel?)

[binstream]

Which platforms which are covered now won't be covered if DX9 is dropped. I was under the impression that for nVidia OpenGL offers more features on XP. (AMD?,Intel?)

 

It's a matter of hardware install base: only a half of gaming GPUs are DX10 capable now.

[james.blight]

Mobile platform support I think in the long run is essential, even for simulation. A simulation company I use to work for was bought by a large german rail company. Thier vision for the future was to allow their customers to have handheld 3D simulators that they could use to diagnose problems, train staff, and order new parts. Just my opinion :)

[cory.sharplin]

+1 to drop directx9, as I really need 8+ terrain layers. And, who really plays in DirectX 9...people who don’t care and have low end systems, let's stop this limiting Unigine.

[danni.coy]

Are the features limited by the hardware or by the DX9 Api? how does this compare to the OpenGL 2.0ES stuff. (could you limit dx9 to the simple shader set does?)

 

Our work does not require dx9 compatiblity at all.

Visual quality is very important to us. The large world support will make it possible to take on jobs we otherwise couldn't but nothing that I am aware of requires it in the next couple of months. We are also very happy about the editor rewrite all the artists in our studio feel that this is both necessary and long overdue.

 

What I would really like to see is some good documentation on using/extending the shader system.

[frustum]

I will try to implement resource streaming this days. It will be very simple solution:

Special Node object which can load they own children nodes.

 

NodeBlock {
 void load();
 int isLoaded();
};

 

ObjectMesh will have function to force load mesh geometry.

ObjectGrass and WorldClutter will work without update stalls.

 

Are the features limited by the hardware or by the DX9 Api? how does this compare to the OpenGL 2.0ES stuff. (could you limit dx9 to the simple shader set does?)

 

Actually OpenGL ES2.0 render system don't have terrain object.

[binstream]

Each project has its own specific requirements to the 3D engine, we are working on delivering the most required features.

However, we are open for custom feature development (or prioritisation of some features) for some reasonable fee. Please contact licensing@unigine.com on that.

[binstream]

Updated SDK with improved streaming will be available within a week.

[alexei.garbuzenko]

Actually, there is no DX9 hardware that is able to run all Unigine features (may be except for GeForce 8800GTX?) so DX9 is needed only for XP support but it is possible to use OpenGL mode on XP for most cards. I think dropping DX9, while leaving OpenGL on XP/Mac/Linux and DX10/11 on Vista/Win 7/Win 8 is acceptable tradeoff for new features.

On the other hand I agree with danny.coy that simple shader set could be used on DX9 for backwards compatibility with simple meshes instead of procedural terrain. Also terrain pixel shader is way too complex for most low-level video cards so replacing it with meshes gives significant performance boost with acceptable picture quality.

 

Just as a sample, optimized mesh vs procedural terrain:

- procedural, 65-67 fps

 

- mesh, 85-87 fps

 

Screenshots are taken on GF 9600GT and it is not reasonable to use mesh terrain on such card, but on GT310M it boost fps from 20 to 35+.

[pascal.winistoerfer]

+1 For this Update! Long waited for the Character Animation Editor! Would be nice if we could see this demo video that is work in progress, especialy how you made the wide view without that it hangs up. magic or true objects in background? if ther's a way to see this live binstream, u may mail it to me or manuel? :)

 

cheers

[binstream]

As I said before, "Valley" demo is in development now, we are testing new day/night system and large world scenario. I hope the project will be available publicly in about 3 months. All of the objects are 3D ones (except for trees impostors)

[ulf.schroeter]

Denis, will tree impostors be based on ObjectGrass as in the older city demo or is it planned to use an optimized tree impostor system for blending between 3D trees and billboards ?

[ulf.schroeter]

NodeBlock {
 void load();
 int isLoaded();
};

 

isLoading(), unload() and/or cancel() function would be helpful to abort started load() operation in case of fast movements/teleports. Also defining/updating the priority of a new/started load() would allow flexible load strategies.

[frustum]

isLoading(), unload() and/or cancel() function would be helpful to abort started load() operation in case of fast movements/teleports.

 

The system is quite different.

 

First of all we should update the resources of NodeSector. This operation can be performed on initialization step:

 

sector.updateMeshes(); // finds all static meshes in the children nodes

sector.updateTextures(); // finds all textures in the children object materials

sector.updateImages(); // finds all image masks of ObjectGrass and WorldClutter

 

On engine update we should call "load" functions manually:

 

sector.loadMeshes(); // loads all static meshes, returns 1 when meshes are loaded, after that we can perform intersection tests and physics without stalls

sector.loadTextures(); // loads all textures from the object materials, returns 1 when textures are loaded

sector.loadImages(); // loads all mask images, returns 1 when images are loaded.

 

Loaded content can be unloaded automatically in case of limited amount of video memory if we don't call this functions each frame.

 

This functions aren't asynchronous from the script point of view. They can be wrapped into the script thread and call callback when the resources are ready:

 

void load_meshes(NodeSector node,string callback) {
while(node.loadMehes() == 0) wait;
call(callback);
}
thread("load_meshes",sector,"my_callback");

 

Another example is:

 

int init() {

// get sector
sector = node_cast(engine.editor.getNodeByName("sector"));

// update resources
sector.updateMeshes();
sector.updateTextures();

return 1;
}

/*
*/
int update() {

// load resources
if(sector.loadMeshes() == 0 || sector.loadTextures() == 0) {
	engine.message("Loading...");
	return 1;
}

// enable sector
sector.setEnabled(1);
engine.message("Ready");

yield 1;

// actual udpate is here

return 1;
}