ArtifexTerra Terrain Editor [1.2 Beta Release 10.3.14 Pg.16]

[Nauk]

Totally awesome Nice choice of pics too, thanks a lot Beauty, much appreciated!

[Nauk]

Hello everyone, after a good break apart from some minor fixes I started working on Artifex again. Since Artifex has been tested and running stabile with only some minor bugs reported for round 3 years now I decided to make a clean repack with the latest update and do some maintenance on it to lift it out of beta testing and call it a 1.0

DotScene Converter:
All features are fully working in the free version without restrictions and will remain free. RC1 is a still a zip archive and RC2 will be coming soon with a real installer and will release the SQlite-to-Ogre dotscene converter again. The converter is based on Php-Gtk and fully scripted so you can easily modify it to whatever XML output you need for your project!

Website stuff:
I also took care of the timeout problems regarding the download, so people with slower connections should be able to obtain it now too. Furthermore MOC has been added to the page again and there is a online manual now on the homepage that explains every function of Artifex Terra 3d in detail and in case you don't want to use the one inside the app. The forum didn't make it back but instead I opened a facebook page for support and discussions: http://www.facebook.com/ArtifexTerra3D

Future plans:
Next thing to happen is a UI overhaul and I am going to replace the current one with QT. I have been working on a Gtk Version previously like anounced before, but the DirectX Bug and the deployment nightmare with Gtk is too much of a hassle, so I decided to root for QT instead. The new UI will also make it a lot easier for me to extend Artifex. Paging support will come too and apart from that I have a couple of rather nice features in the work that I want to surprise you with!

You can get the 1.0 here: http://www.3d-terrain-editor.com/
We will also add a torrent download soon.

Enjoy!
//Nauk

[Beauty]

Hi Nauk,

today I told a friend about Artifex Terra. This was the reason to look to this forum topic again.
I'm very happy to see that you continue your great editor.
On the other hand I'm very sad that there was not any feedback to your last post.

It would be nice if ArtifexTerra switches to the new "official" Terrain Component of Ogre, because will be (or already is) the new terrain standard solution. (I suppose editing functionality is supported by its API.)
Also the accepted Google Summer of Code project Improve and Demo the Terrain System will increase the interest in the Terrain Component. An other accepted GSoC project is Volume Rendering with LOD aimed at terrain (Voxel technique).
When Artifex Terra has support of the Terrain Component much more people could be interest in using your editor (my point of view).
One of Ogres problem is the lack of good content pipeline.
Artifex Terra is a nice tool, which could hit into the gap.

What do you think about switching to the Terrain Component?

[Jeanbono]

Hello Nauk

Like Beauty said,I' m happy to see your project alive.
I switched to delphi last time because c++ is a little difficult for me...
I think ArtifexTerra can be use with any language, just maybe by adding some features like:
-more pass (9 to 12 or 16 max) ?
-possible export the heightmap in a grayscale bitmap (8/24 bit) ?
-export alpha map in bmp/jpg ?

I can make a loader under glscene (delphi) for ArtifexTerra

Keep up the good work my friend!

[Beauty]

-possible export the heightmap in a grayscale bitmap (8/24 bit) ?
-export alpha map in bmp/jpg ?

Good idea.

By the way:
* 16 bit precision for grayscale is better than 24 bit as RGB representation (8 bit per channel)
* Please don't use BMP. It's uncompressed and huge. For the case of lossless compression I propose the PNG format instead.

[Mind Calamity]

The slide to download doesn't work in Chrome. You should fix that. Amazing tool BTW!

[Nauk]

@Beauty: Thanks for the really nice feedback! I am currently exploring and toying around with the new Terrain component. First thing I am going to provide is a loader so Artifex scenes can be used with the new Terrain. Other than that I am exploring different paging options, mainly with the goal to page ETM too, since that is a really nice Terrain component, stabile and easy to use. I just compiled it against Ogre1.8 and it still works fine.

@Jeanbono: Thank you very much! Yes Artifex output can be used with any language or API as long as you convert the shader to GLSL, rest is generic. Artifex can already handle 9 textures per pass, which is the hardware limit for shader model 2 as far as i know, apart from that you can add as many passes as your machine can handle in the material and shader code. The heightmap right now can be exported as 16bit (meaning 16bit per color) grayscale PNG, using less than that will result in data erosion. Most accurate is to load the binary float file, should be easy to convert it to delphi if you look at the loader code. And sure I would be happy if you provide a delphi loader!

I just now opened up a sourceforge page for Artifex addons, loaders, samples and user contributions: https://sourceforge.net/projects/artifexterra3d/ I also will park a copy of the ETM sources there up to date with the latest Ogre version.

@Mind Calamity: Thanks a lot for the compliment! What Chrome version are you using? I am using Iron which is a little stripped and simplified Chrome fork and that works fine. So if you tell your version I can reproduce the bug and fix it.

[Nauk]

Here is some sample code to show how to use the Artifex / ETM or any Ogre material with the new Terrain.
SimpleTMG.h:

Code: Select all

#ifndef __SIMPLETMG_H__
#define __SIMPLETMG_H__

#include "Ogre.h"
#include "OgreTerrainMaterialGenerator.h"

// Simple Terrain  Material Generator sample to show how to use Ogre .material files with the new Ogre::Terrain

class SimpleTerrainMaterialGenerator :
      public Ogre::TerrainMaterialGenerator
   {
   public:

      SimpleTerrainMaterialGenerator() :
         Ogre::TerrainMaterialGenerator()
      {
         mProfiles.push_back(OGRE_NEW OgreMaterialProfile(this, "OgreMaterialProfile", "Profile to use Ogre .material files"));
         setActiveProfile("OgreMaterialProfile");
      }

      class OgreMaterialProfile : public Ogre::TerrainMaterialGenerator::Profile
      {
      public:
         OgreMaterialProfile(Ogre::TerrainMaterialGenerator* parent, const Ogre::String& name, const Ogre::String& desc) :
            Ogre::TerrainMaterialGenerator::Profile(parent,name,desc)
         {
         }

         virtual ~OgreMaterialProfile() {}
         Ogre::MaterialPtr generate(const Ogre::Terrain* terrain)
         {
            Ogre::MaterialManager& materialManager = Ogre::MaterialManager::getSingleton();
			// Set ETM material
            return materialManager.getByName("ETTerrainMaterial");
         }

		
         Ogre::MaterialPtr generateForCompositeMap(const Ogre::Terrain* terrain)
         {
            return terrain->_getCompositeMapMaterial();
         }

         Ogre::uint8 getMaxLayers(const Ogre::Terrain* terrain) const
         {
            return 0;
         }

         void updateParams(const Ogre::MaterialPtr& mat, const Ogre::Terrain* terrain) {}

         void updateParamsForCompositeMap(const Ogre::MaterialPtr& mat, const Ogre::Terrain* terrain) {}

         void requestOptions(Ogre::Terrain* terrain) {}
      
      };
   };
#endif

Referring to the Terrain Basic Tutorial 3, you would use it like this:

Code: Select all

    mTerrainGlobals = OGRE_NEW Ogre::TerrainGlobalOptions();
 
    mTerrainGroup = OGRE_NEW Ogre::TerrainGroup(mSceneMgr, Ogre::Terrain::ALIGN_X_Z, 1025, 5000.0f);
    mTerrainGroup->setFilenameConvention(Ogre::String("BasicTutorial3Terrain"), Ogre::String("dat"));
    mTerrainGroup->setOrigin(Ogre::Vector3::ZERO);    
    
    TerrainMaterialGeneratorPtr mMTerrMatGen;
    mMTerrMatGen.bind( OGRE_NEW  SimpleTerrainMaterialGenerator() );            
    mTerrainGlobals->setDefaultMaterialGenerator( mMTerrMatGen );

[Beauty]

Currently I don't have much time for writing, but I quickly want to say that I'm very happy to see that you, Nauk, continues your great work.
To become an ArtifexTerra loader for the Ogre terrain component would open golden gates for many Ogre users.

Also nice to read, that the Editable Terrain Manager is still usable with Ogre 1.8.
(Additionally: It's good news, because ETM is an important basis of ArtifexTerra.)

[duststorm]

I's a nice editor indeed. It's been quite omnipresent since its appearance in the Ogre community. I don't think there are many Ogre users that haven't at least built one test map without one of its meshes.
I'm very happy to hear you are still supporting it!

[Bulker]

Hello, I would really like to try the terrain editor but I am getting an exception when running with Ogre 1.8 (visual studio 2010 and windows 7):

Code: Select all

No Factory found for scene manager of type 'TerrainSceneManager' in SceneManagerEnumerator::createSceneManager at ..\..\..\..\OgreMain\src\OgreSceneManagerEnumerator.cpp (line 182)

[Nauk]

@duststorm: Thanks! The modelpack seems to have gone a little bit viral, we are very happy about that

@Bulker: The TerrainSceneManager is not longer part of Ogre1.8. So you can do 4 things to make it work:
- Use ETM (Enhanced TerrainSceneManager), you find a version that works with Ogre 1.8 here: http://sourceforge.net/p/artifexterra3d ... re1.8_VC9/
ETM's addon forum can be found here: http://www.ogre3d.org/addonforums/viewforum.php?f=16

- Use Ogre 1.7

- Use the ETTerrain.material with the new Ogre::Terrain. If you scroll up a bit you see a code sample that shows you how

- You wait a bit, I am currently working on a Artifex Sceneloader for the new Ogre::Terrain component.

[duststorm]

I am currently working on a Artifex Sceneloader for the new Ogre::Terrain component.

Great!

[Nauk]

I am currently working on a Artifex Sceneloader for the new Ogre::Terrain component.

Great!

I am making ok progress with that, biggest problem is the lighting / shadowing artifacts you get from the skirts if you have the lighting in an extra pass like Artifex has it now. I tried various things now for over a week So as I see it right now there is either all 9 textures, global normal mapping / lighting, but no texture normalmapping, or if you want to have normalmapping per texture layer you can only use the first 5 texture slots in Artifex. So there will be 2 loaders and I will upload another one with multipass lighting and skirt errors to sourceforge so maybe someone with more clue about shaders than me can help me fix that, if it is fixable at all. Right now I am thinking the decision of having skirts instead of stitching is causing more problems and cutting down a great deal on the material flexibility of Ogre::Terrain than the speed benefit is worth.

[duststorm]

I also noticed that those skirts make it hard to do realtime self-shadows on terrain, they cast weird false shadows.
I haven't found a good solution for it either. The only thing I can currently think of is adding a different material to the skirts, but that would result in a higher batch count. Unless maybe all skirts could be rendered as one batch...

Maybe a shader hack that will not render shadow casters for faces with horizontal normals? But that would also exclude steep rock walls from terrain possibilities and it would probably also be pretty costly.

[Nauk]

I also noticed that those skirts make it hard to do realtime self-shadows on terrain, they cast weird false shadows.
I haven't found a good solution for it either. The only thing I can currently think of is adding a different material to the skirts, but that would result in a higher batch count. Unless maybe all skirts could be rendered as one batch...

Maybe a shader hack that will not render shadow casters for faces with horizontal normals? But that would also exclude steep rock walls from terrain possibilities and it would probably also be pretty costly.

I was thinking about that too, coming to the same conclusion. And yes big question is if you can blend them in homogenously at all, they need to have some sort of light-calculation that matches the rest without flashing out. I have the formula commented out waiting in the shader, but I didnt have the time to experiment with it yet. Performance wise if it is doable at all, it would coming down to a test I guess. Either way stitching (optional?) would spare a lot of material hacking and work-around in that regard. Looking for a solution on the boards, there is quite a number of threads where people report having problems with it and I have yet to find one being flagged solved. The performance hit for stitching is imho neglectable on current hardware. Also optional mesh normals and tangents would make the whole thing much more flexible and consistent in use with Ogre's standard material system. That way you could save one precious texture slot from the global normalmap if you need it. Interface wise a convenient Terrain->setMaterial("MaterialName") is really missing too to be consistent with the rest of Ogre's API philosophy.

[FlorianGeorge]

Hello Nauk, great Project! I'd like to try using it in my application.

When trying out the Sample Loader, some notes:

1. A lot of vectors and maps are being used without a namespace, and there are quite a few "using namespace std; using namespace Ogre;" statements that confuse my VS2008 compiler, I have to add std:: to all of them to compile properly

2. Is your project using OIS > 1.2? For some reason (yeah, yeah, I should upgrade) I am using 1.2.0 at the moment and had to add some lines to the ArtifexLoader InputManager, replacing numKeyboards and numMice with getNumberOfDevices(OIS::Type) if a lower version was detected:

Code: Select all

        // If possible create a buffered keyboard

// fix the spelling bug difference between the SDK versions:
#ifdef __MINGW32__
        if( mInputSystem->numKeyBoards() > 0 ) {
#else
  #if (OIS_VERSION_MAJOR <= 1 && OIS_VERSION_MINOR <= 2)
        if( mInputSystem->getNumberOfDevices(OIS::OISKeyboard) > 0) {
  #else
        if( mInputSystem->numKeyboards() > 0 ) {
  #endif
#endif
            mKeyboard = static_cast<OIS::Keyboard*>( mInputSystem->createInputObject( OIS::OISKeyboard, true ) );
            mKeyboard->setEventCallback( this );
        }

        // If possible create a buffered mouse
#if (OIS_VERSION_MAJOR <= 1 && OIS_VERSION_MINOR <= 2)
        if( mInputSystem->getNumberOfDevices(OIS::OISMouse) > 0) {
#else
        if( mInputSystem->numMice() > 0 ) {
#endif
            mMouse = static_cast<OIS::Mouse*>( mInputSystem->createInputObject( OIS::OISMouse, true ) );
            mMouse->setEventCallback( this );

            // Get window size

3. Is the mountain with the tower on top of it a different technique than the other mountains? In my Sample ArtifexLoader, all mountains and hills are displayed correctly, including the small hill with the bridge and a tower on it, but the "large" mountain range with the tower on top is insivible, leaving the tower floating in thin air. I compiled the loader with Ogre 1.7.2, the Grass is also not displaying maybe because of this, but I was curious why that single mountain was handled differently than the other ones.

[Nauk]

Hello Florian, thanks for the feedback , about 1 and 2, you are totally right with that, the loader code is 3 years old, back then Ogre 1.4x you didn't need to add the namespaces because it was somewhere global in Ogre already. To point 3, no there is no different technique, I simply forgot to update the correct PNG heightmap back then, so if you load the terrain from the "artifex_terrain.bin" file instead (Artifex is by default saving to a binary float array to avoid data erosion), the mountains will display correct. If you want to use the "ETterrain.png" heightmap instead, open the file dialogue (Ctrl+F) in Artifex and hit "Export the terrain as PNG". The grass I have to investigate, going to do that right away and let you know soon.

[Nauk]

...I compiled the loader with Ogre 1.7.2, the Grass is also not displaying maybe because of this,...

Been a while since I looked at the old loader code. Now looking at it the answer to that is quite simple, I didn't include the PagedGeometry dependency in it to reduce the filesize. So if you want to see the grass you have to include PagedGeometry to be found here: http://www.ogre3d.org/addonforums/viewt ... 14&t=14411 into your project and feed it with what

Code: Select all

 void ArtifexLoader::loadGrassSettings() 

loads from the zonesettings.cfg into following variables:

Code: Select all

mGrassCoverChannel="G";
mGrassColourMap="ETbase.png";
mGrassMaterial="pg_grass";
mGrassAnimate=true;
mGrassDensity=1.5f;
mGrassRange=150.0f;

The values above resemble a working default configuration.

Hope that helps

Note: PG Version I used back then was 1.05, latest is 1.1.1 which I haven't tested yet.

[Nauk]

... so if you load the terrain from the "artifex_terrain.bin" file instead...

Easiest way to do that is delete or rename the ETterrain.png the loader will automatically pick the binary file then if you use ETM as terrain component. Working with the standard TerrainSceneManager in Ogre1.7 you need the PNG heightmap.

[FlorianGeorge]

[...] the loader code is 3 years old, back then Ogre 1.4x [...]

I just checked the differences between OIS 1.0, 1.2 and 1.3. Apparently it was the other way round, your code was made for an OIS older than 1.2, so the "<=" in my change proposal needs to be " >=" instead in InputManager.cpp:

Code: Select all

        // If possible create a buffered keyboard

// fix the spelling bug difference between the SDK versions:
#ifdef __MINGW32__
        if( mInputSystem->numKeyBoards() > 0 ) {
#else
  #if (OIS_VERSION_MAJOR >= 1 && OIS_VERSION_MINOR >= 2)
        if( mInputSystem->getNumberOfDevices(OIS::OISKeyboard) > 0) { // For OIS 1.2.0 and above
  #else
        if( mInputSystem->numKeyboards() > 0 ) { // For OIS 1.0 and below
  #endif
#endif
            mKeyboard = static_cast<OIS::Keyboard*>( mInputSystem->createInputObject( OIS::OISKeyboard, true ) );
            mKeyboard->setEventCallback( this );
        }

        // If possible create a buffered mouse
#if (OIS_VERSION_MAJOR >= 1 && OIS_VERSION_MINOR >= 2)
        if( mInputSystem->getNumberOfDevices(OIS::OISMouse) > 0) { // For OIS 1.2.0 and above
#else
        if( mInputSystem->numMice() > 0 ) { // For OIS 1.0 and below
#endif
            mMouse = static_cast<OIS::Mouse*>( mInputSystem->createInputObject( OIS::OISMouse, true ) );
            mMouse->setEventCallback( this );

            // Get window size

I don't have MinGW, maybe that part needs to change too now, but I wouldn't blindly change that part and rather wait until someone using MinGW comments on it.

To point 3, no there is no different technique, I simply forgot to update the correct PNG heightmap back then, so if you load the terrain from the "artifex_terrain.bin" file instead (Artifex is by default saving to a binary float array to avoid data erosion), the mountains will display correct. If you want to use the "ETterrain.png" heightmap instead, open the file dialogue (Ctrl+F) in Artifex and hit "Export the terrain as PNG".

... so if you load the terrain from the "artifex_terrain.bin" file instead...

Easiest way to do that is delete or rename the ETterrain.png the loader will automatically pick the binary file then if you use ETM as terrain component. Working with the standard TerrainSceneManager in Ogre1.7 you need the PNG heightmap.

Thanks, exporting the png heightmap worked. I'm using Ogre 1.7.2 in one project and the 1.8 repository branch in a different one, and the ETM (yet) in none of them, so I needed the png which should work in any situation.

...I compiled the loader with Ogre 1.7.2, the Grass is also not displaying maybe because of this,...

Been a while since I looked at the old loader code. Now looking at it the answer to that is quite simple, I didn't include the PagedGeometry dependency in it to reduce the filesize. So if you want to see the grass you have to include PagedGeometry to be found here: http://www.ogre3d.org/addonforums/viewt ... 14&t=14411 into your project and feed it with what

Code: Select all

 void ArtifexLoader::loadGrassSettings() 

loads from the zonesettings.cfg into following variables:

Code: Select all

mGrassCoverChannel="G";
mGrassColourMap="ETbase.png";
mGrassMaterial="pg_grass";
mGrassAnimate=true;
mGrassDensity=1.5f;
mGrassRange=150.0f;

The values above resemble a working default configuration.

Hope that helps

Note: PG Version I used back then was 1.05, latest is 1.1.1 which I haven't tested yet.

Ah right, between Ogitor 0.4.4 and the current (Bitbucket Version)/(Snapshot), in the DotSceneLoader support for the GrassLoader was added, I will have a look at that code to see how to add it to the ArtifexLoader too. Using PG 1.1.4 atm.

[Nauk]

You are definately right about the inputmanager, thanks for pointing that out Florian . The new Artifex loader I am working on right now is supporting grass loading too, short WYSIWYG. I am working on several version, from simple minimal barebone beginner friendly up to all dependencies included and host them over at sourceforge.

[FlorianGeorge]

I am working on several version, from simple minimal barebone beginner friendly up to all dependencies included and host them over at sourceforge.

Sounds good. Maybe make a Bitbucket Mercurial repository? That would probably make it easier to submit patches and add extensions.

[Nauk]

I am working on several version, from simple minimal barebone beginner friendly up to all dependencies included and host them over at sourceforge.

Sounds good. Maybe make a Bitbucket Mercurial repository? That would probably make it easier to submit patches and add extensions.

For now I used Git on Sourceforge because I figured that is probably the most commonly used versioning system: http://sourceforge.net/projects/artifexterra3d/ maybe I change later, let's see

[Nauk]

After lots of forum-digging, puzzling together documentation, headache and testing I finally got the first acceptable results rendering an Artifex made terrain with the "new" Ogre::Terrain system :


More to come soon(tm)