RealXtend Tundra 2.4-RC1 is out!

121 views
Skip to first unread message

Jukka Jylänki

unread,
Nov 16, 2012, 12:18:04 PM11/16/12
to realxt...@googlegroups.com, real...@googlegroups.com
Hi everyone,

it's a grand update time for Tundra! The newest and latest version is
coming out, and due to the changes aplenty, it deserves an up-front
Release Candidate version so that everyone can test its functionality.

Avoid having a boring weekend and download the RC1 for Windows from here:
http://code.google.com/p/realxtend-naali/downloads/list

Unfortunately there isn't yet a build for OSX, due to some last-minute
build problems creeping into the repository, but those will be resolved
before the 2.4 release.

For a (technical) full list of changes, see

https://github.com/realXtend/naali/compare/tundra2.3.3.1...LudoCraft:ffb9cceefa4dcad95740032aa27317161d76a0d6

Have a nice weekend!

jj

Jonne Nauha

unread,
Nov 16, 2012, 12:56:57 PM11/16/12
to realXtend, realxt...@googlegroups.com
Holy crap that is a lot of commits/code :) 

Showing 303 changed files with 17,813 additions and 30,906 deletions.

Lots of nice features and bug fixes, if fact so many that Jukka might have a hard time constructing a sensible changelog. Maybe making the changelog mention the biggest changes and then have a full link list to the pull requests that were merged. Usually those have nice descriptions for example one of mine (thats in this release): https://github.com/realXtend/naali/pull/508

I know it takes hours and hours to build the changelog by just looking at the commits even if you remember most of the bigger things. Just an idea.

Are there any pull requests that might be merged before final?

Best regards,
Jonne Nauha
Adminotech developer



Jukka Jylänki

unread,
Nov 29, 2012, 9:32:04 AM11/29/12
to real...@googlegroups.com, realxt...@googlegroups.com
Hello,

the 2.4-RC1 proved to work pretty well. Now that the OSX build and
deployment path has been fixed after the detected regressions, it's time
for Tundra 2.4 release for both Win32 and OSX.

Changelog is at
https://github.com/realXtend/naali/blob/884ee1c8043b04b580c08ad1b49045c4f172e8d1/WhatsNew.txt

Binary downloads at
http://code.google.com/p/realxtend-naali/downloads/list

Can't wait to turn all my scenes to Collada now with brand new support for
it! And packaging to zip files will make the loading even smaller still.

Thanks to Adminotech, CIE, LudoCraft, Eino Keskitalo, th3flyboy and all
the others I missed for contributing!

jj

Peter Steinlechner

unread,
Nov 29, 2012, 3:54:56 PM11/29/12
to realxt...@googlegroups.com
Hi Jukka and all realXtend devs

thanks for this latest version - i specially like the collada support, even if it took me a bit to figure out how it works as i first tried to import the collada files via the scene import option in the scene editor instead of first importing them via Assets.
Something i didnt figure out yet is the option of using zipped asset bundles - i could upload the zip file via assets - but where to go from there? (of course i could manually unzip it, but dont think that was your intention)

Also i noticed that on my multi screen system the sky disappears and turns black, when i drag tundra from one screen to the next. This also happens with the browser GUI and the  UI less viewer, where except for the main menu everything turns black. Same also happens in CAVE mode. - i tested this on a Win7 + nvidia 285 GTX with 1GB dedicated ram and actual drivers.

Thanks again for this latest release
Pedro 




Jonne Nauha

unread,
Nov 29, 2012, 4:24:11 PM11/29/12
to realxt...@googlegroups.com
Hey Pedro,

As you might have already figured out collada is supported via the Mesh components mesh ref attribute. So instead of using Ogres .mesh as the ref, you can also use .dae files. It will read the .dae mesh and if the .dae references to textures it will load them. The texture refs can be relative to the .dae file itself or be URLs to point into other web resources. This is how I understood it from looking at the code anyways (I didnt code this myself). So the dae itself can be hosted on the web and used as http ref, if it has relative texture refs like "images/my.png" it will look for them with the location of the .dae as the base. If textures are found, in memory materials are generated with the texture and set to the mesh. You can also override with your own material by setting the Mesh components materials as usual.

Tundra AssetAPI got a new "asset bundle" concept. This means that we now have a notion of assets that actually serve other assets. When I made this I thought "bundle" might be good name for it. Anyways, the new plugin ArchivePlugin implements one such bundle type that knows how to handle .zip files and provide sub assets from inside of it. This is all done via the new IAssetBundle interface and we can add other types of bundles in a similar fashion with other plugins in the future.

I guess I went into little too much detail there, here is how you use them: Any asset reference in Tundra can now point to inside a zip file, and I do mean any, its totally transparent to the code that is using/requesting the assets. So for example you have a Mesh component that has:

wall.mesh as the mesh ref
wall1.material and
wall2.material as the material refs

And lets say wall1.material has a texture ref of wall1.png and wall2.material wall2.dds

You can now zip all these files into for example myassets.zip (you decide the name, it can be anything). Then you change in your .txml or change them live in Tundra and save to a new .txml the refs to be like this:

myassets.zip#wall.mesh
myassets.zip#wall1.material
myassets.zip#wall2.material

You are done. You don't have to modify the texture references inside the materials, but the textures need to be inside the zip file next to the materials. You can also do sub folders inside your zip files, for example meshes/wall.mesh and materials/wall1.material and make the asset refs to myassets.zip#meshes/wall.mesh etc.

Now when Tundra goes to look for these assets, its going to fetch the zip file and then get the assets from there. And of course this zip can be put to the web in which case your refs would be in the form of http://www.mysite.com/assets/myassets.zip#wall.mesh. The benefit of zipping up your assets is maxed when you use http assets. A major point of this feature was to dramatically reduce HTTP requests to the web, this will save a lot of time if you have hundreds or thousands of (small or big) web asset refs in your scene. Now you bundle everything into a single zip, we make one request to the web. Additionally the content is compressed which makes the download faster as well. One downside is that if you change, add or remove file(s) inside the zip file, our asset system will detect it has changed and refetch it from the web. This might mean a big download even if a small material file was modified/added/removed. So you might want to zip things up only after you know they wont be changed frequently. If the zip has not changed in the web source, we dont download anything but use the cached zip file and its contents.

I've seen dramatic improvements when porting scenes into zip files. I recommend it if you are using web refs and have big number of assets. For local development it wont matter too much as no downloads are made. Of course there as well it might make a difference in keeping your scenes working dir looking nice/clean and when you do put the scene to the web its already packaged.

Let me know if you have any more questions.

Best regards,
Jonne Nauha
Adminotech developer



Jonne Nauha

unread,
Nov 29, 2012, 4:29:44 PM11/29/12
to realxt...@googlegroups.com
For the multimonitor question: We have standing issues about this. On directx if you change the main window to another monitor Ogre does not like it and resets some things to be black. Also ive noticed that the 2D user interface overlay disappears.

I've heard people report that this works fine with OpenGL even on windows. But for that you need to build Tundra yourself, setting the directx build flag to zero here https://github.com/realXtend/naali/blob/tundra2/CMakeLists.txt#L233 and running Tundra with --opengl parameter https://github.com/realXtend/naali/blob/tundra2/src/Core/OgreRenderingModule/Renderer.cpp#L271

More details on the bug can be found from the issue tracker: https://github.com/realXtend/naali/issues/457 https://github.com/realXtend/naali/issues/545

Best regards,
Jonne Nauha
Adminotech developer



antont

unread,
Nov 30, 2012, 1:02:22 AM11/30/12
to realxt...@googlegroups.com
On Thu, 2012-11-29 at 23:29 +0200, Jonne Nauha wrote:
> directx if you change the main window to another monitor Ogre does not
> like it and resets some things to be black. Also ive noticed that the
(...)

> I've heard people report that this works fine with OpenGL even on
> windows. But for that you need to build Tundra yourself, setting the

It is possible to at least test on windows without rebuilding too -- just comment out the Direct3D renderer in plugins.cfg (Ogre's plugin conf, used in Tundra the same was as with Ogre normally) and the OpenGL one will be used. Then you can stretch the window to show in multiple screens and everything works fine rendering & uiwise.

This way Tundra renders correctly to n displays - I've so far used with 4 multitaction cells for a wall setup, we should be able to test with 6 soon (as soon as the hardware guys at Uni's tech dept. install a 3rd gfx card to the box .. may need to switch to a new case to fit it in). There's info & video of a similar setup with 24 displays: http://www.multitaction.com/case-studies/

I experienced problems with this way of running with OpenGL in Windows and Jonne suspected that it is due to some compile time conditional code on the Tundra side which are different for direct3d and opengl. But the problems (==crash) only happened when a) logging to a remote server and loading remote assets and b) at exit. So with a local server & scene assets I was able to use a prebuilt Tundra on win to run a demo in a trade show like event, was stable (was used for 2 days).

So if you test like this and experience crashes when logging to remote scenes I recommend you test with local scenes (e.g. the bundled examples).

If the problem with the Direct3d rendering does not go away soon I think it is worthwhile to consider supporting optional OpenGL use in Windows builds. Perhaps the compile time checks in Tundra code could be changed to runtime checks? 

I do hope that newer versions of Ogre and the DirectX11 renderer (with the shiny advertized & MS sponsored win8 support, right?) handle multiscreen setups well too. Our use with the MultiTaction wall may switch to Linux though, at least I'll need to test that for other reasons, and that's what their company does too for large setups.

> Jonne Nauha

~Toni 

Ali Kämäräinen

unread,
Nov 29, 2012, 4:33:22 PM11/29/12
to realxt...@googlegroups.com

Using Tundra with OpenGL does not require building from the sources. Simply use --opengl command line switch.

Peter Steinlechner

unread,
Nov 30, 2012, 2:03:51 AM11/30/12
to realxt...@googlegroups.com
Hi Toni

THANKS :-) disabeling it in the plugins.cfg solved it


--

Ali Kämäräinen

unread,
Nov 30, 2012, 10:54:07 AM11/30/12
to realxt...@googlegroups.com
Cleanest way to achieve this is to either use the --opengl command line switch, or change the "rendering_plugin=Direct3D9 Rendering Subsystem" in tundra.ini (View -> Open Config Folder) to "rendering_plugin=OpenGL Rendering Subsystem".

Grey skies,
Ali Kämäräinen
Reply all
Reply to author
Forward
0 new messages