Josh

If you download it with SVN there's a doxygen folder. There's a footer and header html files, but no index or main page: http://code.google.com/p/recastnavigation/source/checkout

If you had ordered it through the account you are posting on, your account would have automatically been moved to the "Leadwerks Developer" group. If there was an error please email support at leadwerks.com with the email address you used to order and explain the problem.

So where's the documentation?

I'm trying to figure this out myself. His library is completely undocumented...there's just a demo with SDL, a GUI, and who knows what else built into it, so it's impossible to tell what the actual commands to use it are.

That's not a bad idea. Yes, you can link from one actor on one entity to another actor on another entity.

Can you rephrase that? I think we'll be able to save flowgraphs as part of a prefab, so you can set logic up once for a set of entities and then save it as one prefab of interconnected objects.

Mike, the entities are referenced by a unique ID, so the name does not matter. What scares me is what happens when the user resaves a script and the outputs and inputs change. It's very hard to write an editor that dynamically reloads everything. The whole purpose is to have a standard way of making things interact, so that all our scripted objects can talk to one another.

Ah yes, it's in a passworded zip, and only the editor knows the password.

To make an entity in Leadwerrks3D behave, you can drag a script from the asset browser to the actors list in the entity properties editor. Each entity can have multiple scripts attached to it. Each script can have different variables exposed, with control for the GUI they are displayed in. For example, you can specify upper and lower limits of a spinner or a list of choices for a drop down box. Each script attached to an entity, along with its set of properties, is called an "actor" because...it acts. To handle the interaction of different actors, a flowgraph is used. You can drag actors from the entity properties editor into the flowgraph editor. Each actor has inputs and outputs defined in its script. You can connect the output of one actor to the input of another. For example, you can connect the "tick" output of a timer script to the "Resume" output of a mover script, to make the mover translate and rotate an entity at regular intervals when the timer ticks: I hope this makes it more clear how entity interactions can be handled in Leadwerrks3D, even without programming. With this system, we're all working on one big game together, and we can share functional objects without any difficulty.

I believe you can do stuff like this so all actors can access a per-entity value: function actor:Update() self.entity.myvalue="Hello" end Normally you would want to keep them in their own separate spaces, within the actor table. Programming the editor to handle the multi-script attachments and properties, when scripts or objects may be reloaded at any time, is really incredibly gnarly, which is why I have never done anything like this before.

An "actor" is a script attached to an entity, with a set of properties. Each actor has it's own set of variables in Lua that don't interfere with each other. You can have multiple actors, even actors of the same type, attached to one entity, and they are each in their own "space". In the flowgraph, you will actually be looking at actors, not entities. To you and me, it's trivial to just write exactly what you want a script to do. To 99% of the potential market, programming is an utter impossibility, but they can attach a few behaviors to an entity and adjust some settings. It allows game development through visual trial and error. Good eyes! On one hand, this seems like a lot of work just to allow designers to do things without code that programmers can easily do. On the other hand, this means you can code a few scripts, give them to a designer, and let them make some game maps for you with interesting variations of the gameplay mechanisms you programmed.

Below you can see the properties editor. When you select a script attached to an entity, the properties for that script appear on the right. Here we have a simple "Pulse" script that changes the color of the entity along a sine curve. This can be used for making lights that pulsate slowly, or continually turn on and off. Here's what the script looks like. The "--in" tag at the end of the Pause and Resume functions indicate that these functions can be activated in the flowgraph editor. (A node can be connected to them to call them.) --float speed 1 --color color0 0,0,0,0 --color color1 1,1,1,1 --bool recursive function actor:Pause()--in self.paused=true end function actor:Resume()--in self.paused=false end function actor:Update() if ~self.paused then local i = math.sin(AppTime()*self.speed*0.01) self.entity:SetColor(i*self.color0+(1-i)*self.color1,self.recursive) end end Here's our "mover" script, which just performs simple movement and rotation without physics: --vec3 translation 0,0,0 --vec3 rotation 0,0,0 --bool global true function actor:Start() self.paused=false end function actor:Pause()--in self.paused=true end function actor:Resume()--in self.paused=false end function actor:SetTranslation(translation)--in self.translation = translation end function actor:SetRotation(rotation)--in self.rotation = rotation end function actor:Update() if ~self.paused then if self.movespeed~=Vec3(0) then self.entity:Move(self.translation[0],self.translation[1],self.translation[2],self.global) end if self.turnspeed~=Vec3(0) then self.entity:Turn(self.rotation[0],self.rotation[1],self.rotation[2],self.global) end end end Want an entity to animate in a loop? Attach this script to the entity: --int sequence --float speed 1 --bool paused false function actor:Start() self.frame=0 end function actor:Pause()--in self.paused=true end function actor:Resume()--in self.paused=false end function actor:Draw() if ~self.paused then self.frame=self.frame+AppSpeed() self.entity:Animate(self.frame,self.sequence) end end What if we wanted a one-shot animation that plays when something triggers it? We can define an "Enable" function, connect another node to it, and some other event can cause the script to play the animation through once. Here's "PlayOnce.lua": --int sequence --float speed 1 --bool enabled false function actor:Start() self.frame=0 self.enabled=true end function actor:Enable()--in self.enabled=true self.frame=0 end function actor:Disable()--in self.enabled=false end function actor:Draw() if self.enabled then local length=self.entity:GetAnimationLength(self.sequence) self.frame=self.frame+AppSpeed() if self.frame>length then self.frame=length self.enabled=false end self.entity:Animate(self.frame,self.sequence) end end By using these general-purpose scripts we can set up game interactions and interesting behaviors, without coding...but if we need to code something new, the tools are a couple clicks away.

I drew some sketches on paper, and I think the proper way to go about complex structures is to have assign a list of entities that break when a particular entity breaks. This would actually let you set up complex structures that collapse, instead of just shooting paint off of walls.

Just call it..."The Leadwerks".

If you want to shoot identical chunks of plaster off of indestructable wooden frames, then Apex is the way to go. I'm not very impressed with the results and the amount of work it takes to set up. A single object is one thing, but to make structures collapse you have to go through and tag debris chunks to make the whole structure spontaneously fall apart.

I think there's a new general-purpose tool out there to do this with any physics lib that someone posted a while back. I forget what it's called. To me, it always comes down to this increases the art pipeline complexity, and if people can't handle the current workload required, there's no way they'll be able to handle even more complexity. I think the current method of "breaking" objects is a fad people will quickly get tired of when they see how limited it is. Some technology is a real step forward, and some is a trick to look like something it's not. I was initially very interested in this idea, and then I saw the pre-made fragments and the necessity to set each fragment as either "breaks away" or "the whole structure crumbles when this is shot". You can see the effect of this in a lot of videos with pieces that remain suspended in the air because someone forgot to set a fragment's break mode. This has been around for a while, you can download "Warmonger" from 2007 here: http://www.nvidia.com/content/graphicsplus/us/download.asp Real breakage is the way to go in my opinion, even if the results are more simple than what pre-made fragments can do. I really think we can make CSG solids you can chip away the structure of in real-time, and have it break a different way each time.

You need to get with the times. "Multimedia" is a term no one uses anymore because it is so vague. Yeah, I agree with that.

Yes, but someone who has never seen the name Leadwerks before will instantly know it has something to do with 3D or games if they see "Leadwerks3D". There is a reason for this, but you won't find out for a few months at least... No we don't, we have "UDK" because Epic's marketing guys figured out that "Engine" sounds too intimidating to a beginner.

Well, according to Brad, they do not sell to individuals in countries with a high risk of fraud, and they have always had this policy. I don't think it's anything against you in particular. http://www.onlinefraudguide.com/risk-countries-fraud I wouldn't do this myself, but it's their decision to make who they want to sell to. Maybe they've had a lot of problems in the past, and just don't want to deal with the risk.

In the BMX code you are just rendering to a simple gbuffer. The C++ code is using the Framework object, which has a lot more effects and uses HDR by default.

That's a definite probably.

The various parts of the new editor are coming together. Today I got the properties list box drag and drop functionality working. I actually had to go back and rewrite some of the list control rendering code because I haven't used it in a while, but it didn't take long. I'm trying to attack known unknowns first, so we're focusing on the flow graph, AI, and game logic, and everything required to build up to support that. I've already written a CSG editor and an engine with great graphics, so I know I can do that. Gameplay support is what I want to focus on now before I cover old familiar ground. In other news, it has occurred to me that an OpenGL 2 renderer is needed to provide a PC/Mac equivalent of what the iPhone and Android renderer looks like. Leadwerks Engine 2 uses OpenGL 2.1, but this OpenGL 2 renderer won't be anywhere near as advanced. I'm just going to derive a bunch of classes from the OpenGLES 2 renderer, so we can get as close a match as possible to the Android / iPhone render.

Well, I sent an email off to Brad, hopefully he'll see that.

He's asking for more examples. I need to get their engineers in a room with a power point presentation.

That's a little easier, due to the lack of gravity. I would just create a fixed joint and delete the joint when the object was shot. That's an easy way to make bits and pieces of ships break off. That's cool, but it's still pretty limited. I'd like to implement something that works on any CSG solids. The breakages probably will not look as good as the pre-broken DMM stuff, but if I had the choice I'd rather have dynamic breakage that is simpler and looks worse than pre-made breakages that look better but require extra work to set up.