Loading Leadwerks editor files (.SBX) into C++

[MasteR]

After loading "tunnels.sbx" into a simple program it is my job to then recreate lights in the engine.

 

Running the following code:

DrawText(0,0,"%s",(str)GetEntityKey(scene,"class"));
int i;
for(i=1;i<=CountChildren(scene);i++)
{
    DrawText(0,15+(i*15),"%s",(str)GetEntityKey(GetChild(scene,i),"class"));
}

This shows me that the scene loads in as a Pivot entity and all of the other 62 entities created in the Leadwerks editor load in as Models. This means that I am unable to simply create lights in the engine that correspond to the lights created in the Leadwerks editor.

 

I noticed that in the Leadwerks editor entities can’t share the same key (name). This meant that even if I created the scene from scratch with the above problem in mind using:

 GetEntityKey(entity, “name"); 

Was an inefficient process.

 

Upon opening the "tunnels.sbx" file in a text editor the problem became apparent. All entities created in the Leadwerks editor were saved as models, even light entities loaded in an invisible sphere model but more importantly all entities had their class set to "model" regardless of what their actual class was.

 

Based off this information I have some questions and invite discussion:

 

Why does the editor load in invisible spherical objects for entities?

 

When saving the .SBX file why not save lights or for that matter any entity as their actual type? Or even step down and just save their class property as their actual class?

 

Should this loss of data be addressed or am I missing something myself? (Quite probable)

[ZioRed]

I think the lights in the editor (and probably every object you drag from the sidebar) are really models and their behaviour of "creating light" is due to the LUA scripts (see in example at /Models/Entities/Light/Directional/light_directional.lua in your SDK folder).

 

If you load a scene in which you already have added some lights than I think you don't need to recreate the same lights in your C++ code but you have LUA enabled (see the Scene Loading Example thread):

 

TFramework framework=CreateFramework();
//Set Lua variable
BP L=GetLuaState();
lua_pushobject(L,framework);
lua_setglobal(L,"fw");
lua_pop(L,1);

 

However I think this thread should be in C++ Programming section B)

[MasteR]

However I think this thread should be in C++ Programming section

 

For me this issue could be reasonably placed in the C++ Programming section, the Leadwerks Editor section or the Feature Requests section. So I decided to place it in General Discussion instead. I'm quite happy for this to be moved to a more appropriate section for either exposure or relevance.

 

I think the lights in the editor (and probably every object you drag from the sidebar) are really models and their behaviour of "creating light" is due to the LUA scripts (see in example at /Models/Entities/Light/Directional/light_directional.lua in your SDK folder).

 

I'm no expert as I have no scripting experience but my understanding is that the LUA scripts access methods in the Leadwerks engine which if you break it down even further the Ladwerks engine simply access methods in the OpenGL API. Scripts simply make using the engine more accessible to people with little to no programming experience.

 

e.g. taken from the above mentioned script.

 

local object=self.super:CreateObject(model)
object.light=CreateDirectionalLight(object.model)

I believe this script simply calls the Leadwerks engine methods in a way similar to the below C++ example by passing the relevant arguments.

 

private TEntity object = LoadModel(model);
TLight light = CreateDirectionalLight(object);

 

I'm looking for a solution that does not rely on LUA scripting, or on 3rd party classes. And there should be one as both access the same engine methods that I can access directly.

[Guest Red Ocktober]

I'm looking for a solution that does not rely on LUA scripting, or on 3rd party classes. And there should be one as both access the same engine methods that I can access directly.

 

there used to be a function called ProcessScene() that pretty much loaded up all the child entities and instanced em in a scene... i think that's what you're referring to...

 

ever since the lua classes came onto the scene, it hasn't been mentioned much...

 

still... just take a look at the lua code, and you should be able to transpose it into BlitzMAX or c++ or whatever you happen to prefer coding in... it shouldn't be too much of a hassle...

 

good luck...

 

 

--Mike

[Josh]

It's really easy to just use Lua to automatically create lights and things in your scene. You just load the model, and it's automatically taken care of, with the same code the editor uses.

[MasteR]

It's really easy to just use Lua to automatically create lights and things in your scene. You just load the model, and it's automatically taken care of, with the same code the editor uses.

 

As a stand alone statement:

I don't want to use LUA or LEO or Framewerk...and I should not have to. Why? because I have the .DLL.

 

BUT…

 

I'm beginning to understand that the Leadwerks editor is more than just a nice toy which makes it easier for non programmers to create games using the Leadwerks engine. In fact I now feel that the editor and the engine are a package that should be used together to great effect.

The editor is a type of GUI to the Leadwerks engine that not only allows easy map creation but when combined with LUA scripting allows easy game creation (provided you can use the LUA scripting language).

 

I can see the editor relies heavily on LUA scripts and as I did not develop the program myself that’s okay by me. But my opinion is that, as the editor is the other half of the Leadwerks circle, the benefits of its use should be available to developers who choose to access the Leadwerks engine.dll directly, without relying on a 3rd party scripting language. Currently it is not.

 

I understand that many of you will be aware of the below process but it helps underline my issue. I may also be wrong.

When the Leadwerks editor loads a scene it goes through the .SBX (text) file and creates a “model” for each entity present that was dragged and dropped onto the screen. For each entity in the text that loads a .GMF model file the editor will have a look for an accompanying LUA script. If found this script will access Leadwerks engine commands and perform certain actions. e.g. When the cage light model is loaded its accompanying LUA script will, amongst other things, access the Leadwerks engine commands and create a point light entity. This process is also performed when you simply drag and drop a model into your scene.

 

The problem is that when the scene is saved and loaded directly into a program using the LoadScene(); command all dynamically created (LUA script created) entities were not saved in the .SBX file and are therefore not created in your program.

The x amount of staticly created entities are all there but the information pertaining to the dynamic entities they create is lost. In the “tunnels.sbx” example a search for entities after LoadScene(); locates 62 “class=model” entities which is great but there is no way of knowing what the model used to be and do in the Leadwerks editor.

A GetEntityKey(scene,”name”) is not an efficient way of finding this lost information and directly relies upon the proper naming of entities in the Leadwerks editor.

 

To enable the benefits of the Leadwerks editor to non LUA script users I see the following solutions:

 

Dynamically created entities should also be saved in the .SBX file with the relevant “class” key also saved. e.g. “light_point”

 

When all entities in the Leadwerks editor are saved to the .SBX file an additional key “classname” could also be saved to each model, keeping a reference to the major type of entity that the model dynamically creates.

e.g. (LUA script) self.model:SetKey("entitytype","light_point")

 

I acknowledge that my understanding of this may be completely wrong, in which case I’m happy to be educated.

Anything that solves my problem, as right now only LUA script users can get the full benefits from the Leadwerks editor and by that token the Leadwerks engine as each element forms one half of a full circle.

[macklebee]

If you do not wish to use lua scripted objects, you do not have to do so. Just delete the scripts associated with entities but then you will lose the realtime effects that you get in the editor. Or if you wish for some reason to actually set all of the properties of your entities with code other than from lua scripts, then you could always just add this classname yourself by either creating an INI file that has the classname info or add this key to the lua script. Then you could loop thru your scene entities and create/load your entity and set its properties then finally free the editor model afterwards. But offhand I truly do not see why you wouldn't want to use the lua scripts to handle some of your entities properties, especially properties that will not change. But to each his own. If you wish to use some other method than what is currently available, then surely that is your responsibility to implement?

[cassius]

I only use lua script to get into an objects propertise. Just 2 lines of code that never changes. I can't see what the problem is with that. I can still write my program in Bmax or c++ and easily reference all objects placed in the editor.

[Josh]

The reason Lua was implemented this way was so people could get their level "as is" in the editor, with no extra processing. It was unacceptable to many people that they would have to use code to add lights from entity properties, and I didn't want to hard-code those things into the engine. Give it a chance and I think you'll like it.

[Laurens]

When LUA was introduced I felt the same way as you MasteR. I intensely disliked working with LUA but over time it really just is an extra folder in your game map and some scripts that came with the engine anyway. Now I don't have to fuss over a ProcessScene() type of method. You can easily create a game without ever touching it yourself.