Roland

Nothing has changes regarding that. LE2 accepts GMF and DDS. Nothing else

Thanks Josh. Much appreciated

Very interesting reading there Aily. If I do understand you right here, single mesh house with one material is the optimum, as I suspected. To conclude the points given here by you and TheoLogic: "Make it one mesh with on texture if possible. In all cases avoid grouping".

Aha. There is a limit. Its quite high so its no problem in my case, but thanks for that info Lumooja. Don't be such a violent nature. Every house does not need to be torn down to the ground

Yes. We are at the same path. Memory is of no concern, at least if we are talking about a few objects. I have got the advice to keep the polys down by using instances. A good example is the bridge which I talk about in my blog. If I do the whole bridge in my modeler the result is about 1900 polys. By creating some parts in the modeler and assemble them to a bridge in the editor the poly count is reduced to 10% (=190 polys). Looks good on the paper, but what is realy gained by doing this. Obviously some memory is saved, but as you say, memory is of no or at least less concern these days. Now if doing this doesn't end up in a better framerate speed, I cant see why there should be any reason to bother at all. And as all probably knows. Assembling pieces together in the editor is possible in theory, but not i practice. So I don't really see any meaning of this poly count hunt for such objects that we are talking about. One thing that I CAN understand is the case where a building has many materials. Then there may be some speed gain by dividing separating the pieces with same material into a separate gmf. The gain would be that same shader could be used for the complete gmf file. I guess that switching shaders is a thing that might bring speed down a bit.

I know that instances brings down the amount of meshes loaded into memory. Let's take a simple example. A cube. That's 6 Quads or 12 Triangles. When two cubes are loaded we still have only 12 triangles loaded. That saves memory. My question now is. Has this any other advantage besides saving memory. There is still 2*12 triangles to render? The reason why I'm asking is that when creating a house, it can be done in several ways. Either you make the whole thing in your modeler and exports it as single gmf file, or you can divide it into say 4 walls, a floor and a roof and export them as separate gmf files. In the latter case you then assemble the house in the editor (which is very hard to do with current editor). One can easy see that using the 4 wall's approach will result in fewer triangles loaded into memory, but will there be any gain in speed doing this. The amount of triangles are still the same as if we load the whole house as one mesh. Can someone elaborate a but about this.

Haven't come to using particles yet, but this looks great. Must bookmark this one so I don't forget later on.

Yes Brent. I assumed that ZioRed was talking about MonoDevelop

As I understand it you wan't to protect the script source. Maybe this is something for you then Compile more LUA scripts ... ... into single bin file Have not tested my self but I saw that post I thought it could be something for you.

Wow ZioRed. Mono is supporting LUA. I have totally missed that. That is really cool. Have to try it out. Thanks for that info. Roland

Exiting news !

+1 for that

Not exactly. Here is what works perfectly. Modo -> Collada -> UU3D -> GMF If I use Modo -> Collad -> dae2fbx the material is lost on the way. Anyway. I'm satisfied with Modo -> Collada -> UU3D -> GMF But sure it would be cool just to do Modo -> collada and the it would be converted by the editor directly. I realize that there would be much trouble supporting all kinds of formats. Maybe there could be place for 'Load' plugins in the editor so when a dae file is loaded a simple cmd-file would be called. Then conversion could be done by that cmd-file (calling a converter program etc ... ) and the editor would have a gmf file. I don't know. But that would be a really open and simple solution for all kinds of variations. Just a list dae - daeconv.cmd fbx - fbxconv.cmd .... .... somewhere to define what to call for various formats

Thanks Josh. Exactly the answer I was hoping for

In the Editor: If I drag say 10 OilDrums into the scene. Will that result in one copy of the mesh and 10 objects just using that mesh OR will it result in 10 copies of the mesh. In C++: If I load the scene mentioned above.. Will that result in one copy of the oildrum mesh and 10 objects just using that mesh OR will it result in 10 copies of the mesh. Here is the first part of a little bridge I'm working on. As you can see I have 10 objects of the mesh 'Pole'. Will this result in one or 10 meshes in the my C++ program if scene is loaded

Arrgh... Josh. You are a devil teasing us with goodies from the future. How are we supposed to survive until we can lay our hands on all the news. Just joking. Thanks for the updates

Title says it all.

I have only one comment about using memory-pointers as unique id's. "Don't"

Forgot to write the sample in accepted standard style. Used my own personal touch there. Sorry about that.

I don't really understand what you are after but this approach makes a unique id for each object and is safe #include <iostream> using namespace std; class MyClass { static unsigned int _id; unsigned int _myid; public: MyClass(void) { _myid = _id++; } bool operator == ( const MyClass& c ) const { return _myid == c.getID(); } unsigned int getID(void) const { return _myid; } }; unsigned int MyClass::_id = 0; int main() { MyClass a; MyClass b; MyClass* p = &a; cout << "a is " << (a==b?"":"NOT") << " b" << endl; cout << "*p is " << (*p==b?"":"NOT") << " b" << endl; cout << "a is " << (*p==a?"":"NOT") << " *p" << endl; cout << "a id = " << a.getID() << endl; cout << "b id = " << b.getID() << endl; cout << "*p id = " << p->getID() << endl; return 0; } a is NOT b *p is NOT b a is *p a id = 0 b id = 1 *p id = 0 Process returned 0 (0x0) execution time : 0.053 s Press any key to continue.

If that's the case I can agree with you. Use a ID attribute instead and don't mess with the pointers.

Why are you trying to do this conversion? It seems like a adventurous thing to do. Surely there must be a reason to leave safe ground.

File Name: Codeblocks Template for Leadwerks Builder File Submitter: roland File Submitted: 30 May 2011 File Updated: 17 Jun 2011 File Category: Tools C++ CodeBlocksTemplate for LEBuilder Builds a CodeBlocks project containing the standard C++ Spinning Cube Just import the zip-file in Leadwerks Builder Click here to download this file

5 hours!!! Amazing. Would take 5 weeks for me I guess

Great news, Josh. Yes. Indeed simple for the user. This means that we just can zip levels into a pak and load them. Really great when distributing files. For my own game idea it will be perfect as new levels will be loaded from Internet. Great news for me