Josh

You are requesting two contradictory things at once. Are you asking for a Leadwerks modeling and animation program, or an export plugin for an existing program? Or are you just saying you feel overwhelmed by the array of existing modeling programs, and want some solution to making animated characters?

Now I've actually got a LoadScript() command, and a script and an actor are NOT the same thing! Load and run a script: script = LoadScript("mygame.lua"); script->Run(); script->Run(); script->Run(); Attach a script to an entity: script = LoadScript("Mover.lua"); actor = new Actor(entity,script); actor->SetVec3("turnspeed",0,1,0); The script must have a Main() function to be run, and it must contain actor:whatever() functions to attach it to an entity. It's complicated, but the script loads all the actor functions into a table, and then the functions get copied to each actor. That way the engine isn't calling DoString() each time and creating a bunch of unique functions in the virtual machine. So if you have an actor script that is attached to 100 different entities, there is only one set of shared functions, but the actor userdata is not shared, so each one can have different values. It also means you can load a script once and run it multiple times, and that will be faster than executing a file each time, because the parsing step will be skipped.

Are you asking for a modeling and animation program made by Leadwerks that integrates into the engine better?

Two issues in the art pipeline were giving me some doubt. I stopped working on them a couple weeks ago, and I'm glad I did because the solutions became clear to me. Shader FilesFirst, there is the matter of shaders. A shader can actually consist of half a dozen files:bumpmapped.opengl3.vert bumpmapped.opengl3.frag bumpmapped.opengl4.vert bumpmapped.opengl4.vert bumpmapped.opengles.vert bumpmapped.opengles.vert I originally thought the .shd extension would be good for shaders, in keeping with our extension naming scheme, but there's actually no information an .shd file even needs to contain! I also considered creating a simple format that would pack all the shader strings into a single file, and display the different ones for whatever graphics driver was in use at the time, but that approach reeked of future confusion. I'd like to still be able to open .vert and .frag files in Notepad++ or another text editor. I came up with the idea to use a .shd file that contains all these shader files, but instead of packing them into a file format, the .shd file will just be a renamed .pak. That way you can easily extract the original text files, but shaders can be distributed and loaded as a single file. Material TexturesI've been working with a system that uses texture names defined in the shader file. It works and it's really cool, but I think I have something even cooler. Instead of requiring a shader to define texture unit names, it would be less confusing to just decide on a fixed naming scheme and stick with it, something like this:texture0 - Diffuse texture1 - Normal texture2 - Specular texture3 - Reflection texture4 - Emission texture5 - Height And in C++ you would have constants like this: #define TEXTURE_DIFFUSE 0 #define TEXTURE_NORMAL 1 ... If you want to create a bumpmapped material, you can simply assign textures 0 and 1, and the material will choose a shader with the assumption those are supposed to be the diffuse and normal map. If the current surface being rendered contains bone weights, an animated version of the shader will be used. If a shader is explicitly defined, that of course will override the material's automatic selection. This way, all you have to do is drag a few textures onto a material, and 95% of the time no shader will even have to be explicitly defined. This is similar to the materials system in 3ds max. The programmer in me screams that this makes no sense, since texture units are completely arbitrary, but from a usage standpoint it makes sense, since the exceptions to this paradigm probably make up less than 5% of the materials in any scene. Now for custom shaders, you might end up with a situation where you are dragging a texture into the "reflection" slot, when it's really going to be used to indicate team colors or something, but it's still far simpler to say "set the reflection texture with...". Everyone knows what you mean, textures can be set in code without having to look up the slot number in the shader, and there's no ambiguity. Anyways, that's just two small design problems overcome that I thought I would share with you. I think the texture issue really demonstrates the difference between engineering and product design. http://www.youtube.com/watch?v=5U6Hzjz5220

Please use the bug tracker. There's no way I can remember different forum posts throughout the site.

Please use the bug tracker. There's no way I can remember different forum posts throughout the site.

Has anyone used this? It makes big promises. Does it work well?: http://www.mixamo.com/

I'm not clear on what this request is actually asking about.

I've never used the std::multimap before, and have use for it now. Here's the class: class Actor : public Object { public: std::multimap<std::string,Output> outputs; }; I need to add an object into the map, without removing other objects that use the same key: void Actor::AddOutput(Actor* target,const std::string& outputname, const std::string& inputname) { Output out; out.target = target; out.functionname = inputname; outputs.insert(pair<std::string,Output>(outputname,out));???????????? } And I want to iterate through all objects for a given key: void Actor::CallOutputs(const std::string& name) { /*Output out; out = (outputs.find(name))->Second out.Call();???????*/ } Anyone know how to do this?

I am still interested in doing this as a standalone visual tool for shaders, but I agree with Brent's take on using it for game logic. A non-programmer still is going to have no idea how to do anything with it, and a programmer will be similarly perplexed, Now, Rick has been working on something like this, and I think it;s really cool and look forward to seeing what he implements. If he created some tool and sold it to users, that could be really interesting. The consumer in me is intrigued. But I don't want to gamble my engine on this approach, because it's a niche.

Now it's getting cool: teapot = LoadModel("models/teapot.mdl"); Actor* actor; actor = teapot->AttachScript("ColorOscillate.lua"); actor->SetFloat("speed",4.0); actor = teapot->AttachScript("Mover.lua"); actor->SetVec3("turnspeed",Vec3(0,1,0)); actor->SetBool("global",true);

GetEntityAABB?

C# is not officially supported at this time.

I presume the reason for this would be to attach multiple entities to the same actor, in which case there would be no per-entity values in the script. The script would only have values shared across all entities it was attached to. Can you think of a situation where this would be useful? I mean, you could use this so you could just control the values of one actor and have it affect all the entities it is attached to, but it would be very limited because it would only allow shared variables in the script.

Okay, now I have an Actor C++ class that gets created when a script is attached to an entity. You can set and get values on the Actor itself: Actor* actor[2]; Model* teapot = LoadModel("teapot.mdl"); actor[0] = teapot->AttachScript("ColorOscillate.lua"); actor[1] = teapot->AttachScript("PointAt.lua"); actor[1]->SetObject("target",camera);

It's basically just the old target/targetname system from Quake 1, in a visual diagram. The flowgraphs are for scripted events in a level, not for complex game logic like AI. You step into a trigger area, spawn a monster, unlock a door, etc. I see flowgraphs as the final production process, where all your scripted objects and game code are done, and now you put them together in interesting ways.

The command would be executed when the scene is loaded, because the scene would list that entity in the scene as the value. Here's a version of your script I have actually working. Now my teapot changes color AND faces the camera! function actor:Start() self.axis = 2 self.speed = 0.01 end function actor:DrawEach(camera) self.entity:Point(camera,self.axis,self.speed) end

You'd actually want to use AppTime() instead of Millisecs(), and everything would be fine. If you were gradually adding to a value, you would want to modulate it by AppSpeed().

It doesn't need glue code. My understand of the term is that is code I use to expose engine C++ classes to Lua. I'm not sure what you're referring to. The scene file will probably look something like this: entity { script "Scripts/pointat.lua" { target = 487567493 // entity ID in the scene speed = 3 } }

This version blends between two colors. I actually have it working in the render loop now: function actor:Start() self.speed = 1 self.color = {} self.color[0] = Vec4(1,0.5,0.5,1) self.color[1] = Vec4(0.25,1,1,1) end function actor:Draw() local luminance = (math.sin(Millisecs()*self.speed*0.001) / 2 + 0.5) local color = (self.color[0] * luminance) + (self.color[1] * (1-luminance)) self.entity:SetColor(color) end

It will just get loaded from the scene.

That looks right. Then in the editor you would drag the desired entity into the "target" parameter to set it. Alternatively, you could do this in C++: int i = entity->AttachScript("Scripts/actors/pointat.lua"); entity->SetObject("target",targetentity,i);

You must be running the evaluation kit. The real thing is located in "C:\Leadwerks Engine SDK".

Here's an example of a script that will make the entity's color oscillate over time: function actor:Start() self.speed = 1 self.color = Vec4(1) end function actor:Draw() local luminance = (math.sin(Millisecs()*self.speed) / 2 + 0.5) self.entity:SetColor(self.color * luminance) end Basically, I am thinking in terms of what Michael Betke could use. Not to pick on him, but programming is not his area of discipline, nor should it be. With scripts he can attach behaviors to entities and watch it go. Add a couple of these scripts with different speeds set, and you get a random but smooth change in brightness.

i don't believe they have a flow graph, which is where the whole design plan for le3 comes together, imo. I also am a big believer in Lua