Josh

The Leadwerks Merchant Agreement is available here: http://www.leadwerks.com/files/Merchant Agreement.pdf Instructions for applying to become a Leadwerks Merchant will be forthcoming.

The Leadwerks Asset License is available here: http://www.leadwerks.com/files/Asset License.pdf All free and paid files in the Asset Store are distributed under this license. A notice and link has been added to the file display page: http://www.leadwerks.com/werkspace/files/file/214-2-medieval-weapons/

I don't know how the videos should be laid out, so I just left it as is for Tom to do something with. I don't like the big grid of thumbnails, but I don't know what exactly should be done.

I think so, yes

Removing the interior faces may help. It's hard to tell what's going on without seeing the actual .3dw file.

I'm inclined to agree, for the majority of the site. However, the video gallery and possibly blogs are more of a "consumption" oriented page, so I think that situation is a little different. I'm curious to see how it does, anyways. If it feels wrong or isn't successful, we'll drop it. The only thing I require is that the ads be relevant, which is why Adsense is out of the question.

So those objects are things you modeled in another program, and imported into 3DWS?

In fact, I have plans beyond this I have not laid out here. In a few months I want to start playing with the games portal idea. If someone made something like this, in 3D, it would be perfect for trying the idea out with.

This blog is going to actually be about business rather than technology. Here's what's going to happen this summer: First, we need to get this ATI driver bug fixed ASAP. Nothing else can happen until that gets fixed: http://www.leadwerks.com/werkspace/tracker/issue-165-terrain-textures-bug-radeon-hd-5850 The official documentation is coming along well, and I am really pleased with how this has turned out. (Thanks, Aggror!) An updated evaluation kit with some limited programming will be released. One of the biggest appeals of Leadwerks Engine 2 is the ease of C++ programming, and we need to demonstrate that better. With the release of the evaluation kit, we're going to begin an affiliate program. My preference is to have a Facebook and Twitter share buttons in the header that copy the current URL, and adds your affiliate ID into the php arguments in the URL. Then you can just click that to share any page on the site, with your embedded affiliate ID. When a new user comes to the site from that link, your affiliate ID will be detected, and any sale they make will give you 15% of the sale price credit to use in the asset store. if you are a Leadwerks Merchant, you can also have the cash sent to your PayPal account. The Asset Store will be "launched" at this point, meaning I'll put out a lot of news announcements and PR to make a big deal of it. This requires the front page be fixed, so you have the nice scrolling rows of products. I also have to set up a merchant account, which will lower the transaction costs by a lot. Right now, I am losing about $8 on each engine order through PayPal, and that needs to stop. I also need to formulate an agreement for Leadwerks Merchants, so that we can give more people access to sell their stuff in the Asset Store. The tax issues here are pretty serious, so I need formal paperwork to do this. We're opening a new section of the site for videos. You can check out the beta here. I like searching for "Leadwerks" on YouTube and clicking around on videos. The idea here is that if someone is wasting time clicking around on Leadwerks videos, they might as well do it on our site. There's a lot of great videos out there that are easy to miss, so this will gather them in one spot. Best of all, it doesn't require any bandwidth from our server, as YouTube provides the data transfer, and even more importantly, users don't have to upload their videos to two different sites. To add a video, just enter the 11-character YouTube video ID, title, and description. If I have already added your video, and you would rather have it appear under your name, just add it to the database yourself, and I will delete my original entry. My goal with the affiliate system and video gallery is to raise site traffic. Right now we have about 36,000 visits per month. I want to raise that to 100,000 visits per month. Our new dedicated server can definitely handle the load. Finally, we're going to implement advertisements in the video gallery. I want it to be tasteful and relevant. I tried Google Adsense, but it displayed a lot of irrelevant ads. I tried "section targeting" and even set all information to be blocked except a few keywords I chose, but it made no difference. I inquired about AdBrite, and they seem to be the same sort of system of automatic analysis and placement of irrelevant ads; artificial stupidity, if you will. I know my users are interested in video games, 3D models, programming, computer hardware, and art programs. If a system won't let me choose what content is displayed, I won't use it. Therefore, I am going to attempt to find advertisers with relevant content that have affiliate systems. I'd prefer not to sell advertising space and manage accounts, at least at first. So, the ultimate goal here is to raise traffic. More traffic = more LE2 license sales, more asset store sales, more advertising revenue, and more opportunities for you guys. There's potential with this we can only begin to imagine. There is so much to do, I had to draw out a diagram showing the dependency of events, so I can cross them off as they are accomplished: And last, I will leave you with this video, the band from which I am really starting to like, for some reason:

I'm confused about how ToLua++ works. So it wants a "cleaned" header file. Is there some executable that parses this and outputs C++ binding code? I am not sure what I am supposed to compile. Do I just include all source files, or is this the source to the aforementioned glue code generation tool?

Now that video is awesome.

I am replying here because you emailed me about this. Realistically, I don't think you will have success modeling soft bodies as a bunch of rigid bodies and joints. That's now how it's done in physics libraries that support this feature. They have an entirely separate algorithm specifically designed to handle soft bodies. Newton does not support soft bodies, and I don't have any reason to believe it ever will. I told the developer I would have to switch to another physics lib if this was not supported some time in the next 6-12 months, and his response was to compare me to a crack addict, in broken English. So I've had enough of his bad attitude. If you want to give me a chuckle, post your video in the Newton forum, say you are using Leadwerks Engine, and ask if soft bodies will ever be supported: http://newtondynamics.com/forum/viewforum.php?f=9

This issue is definitely a driver bug. I sent a report to AMD and will post when I have confirmation they have fixed it: http://www.leadwerks.com/werkspace/tracker/issue-165-terrain-textures-bug-radeon-hd-5850/

This will do it: require("scripts/class") local class=CreateClass(...) function class:CreateObject(model) local object=self.super:CreateObject(model) function object:Update() self.model:Animate(AppTime()*0.05,1,0,1) end end Not that you also need the animation shader applied in the material. See this lesson: http://www.leadwerks.com/werkspace/page/Documentation/LE2/tutorials/_/programming/cpp/introduction-to-animation-r11

The idea is we might be writing a rocket script right now, but some time in the future we might come up with an entirely new entity behavior that we want the rocket to interact with, without altering the original rocket script. Maybe I'll want to make a special button you shoot to activate, so it has to detect when a rocket hits it. A good case could also be made for having two scripts attached of the same type. A lot of oscillating and gradual motions might use two or three script attachments of the same type, with various settings adjusted to produce a combined output. For example, my vegetation waver code is the combination of a few different sine curves with different frequencies and amplitudes. You wouldn't want to do that in a script, but that's an example of the idea. Each script could just be appended to the end of an entity.scripts table, in which case you could just do this: for script in entity.scripts do if script.Hurt~=nil then script:Hurt(5) end end Then you could just call the function for all attached script, without knowing or caring what other scripts are doing. I need to come up with some more usage examples and see how they would work out.

If that were the case, we'd be looking at something like this for the mover script: function script:Start() self.movespeed=Vec3(0) end self.turnspeed=Vec3(0) end end function script:UpdateMatrix() Print(self.entity.position.x..","..self.entity.position.y..","..self.entity.position.z) end function script:Update() if self.movespeed~=nil then self.entity:Move(self.movespeed) end if self.turnspeed~=nil then self.entity:Turn(self.turnspeed) end end It's not bad, although the extra .entity table is not preferable. Let's say you have a rocket script, and it collides with some entity. If all functions were stored on the entity, you could do this: function script:Collision(entity,position,normal) if entity.Hurt~=nil then entity:Hurt(5) end end But if all information is stored in script subobjects, you would only be able to interact with some classes: function script:Collision(entity,position,normal) if entity.player~=nil then entity.player:Hurt(5) end end

I had to adjust the settings in WHM, instead of a php.ini file. It works for me now. Those two files will each take a while to download, as they are 16 mb apiece. Uploads should also be fixed now.

I believe this has the same cause as the problem uploading files more than a certain size. I filed a ticket with WiredTree. I have set the php.ini file, and the max file size is detected in the system, but it doesn't appear to be working.

I considered something like that, but I'm not convinced it's that great:: function door:Open() self:Turn()--Oh wait, we can not do that, because this is the door... --What if we say "entity" is a value in "door"? It would be entity.door.entity: this.entity:Turn()--Okay, this works alright end function door:Update() this.health --wait, that does not work, unless you want the value contained within "door", in which case GetString("health") would not return it this.entity.health = 100--okay... end It seems like a lot of mess for something that is supposed to be as simple as possible. I really do not like the infinite recursive loop of tables. I suppose you could do something like this in C++: entity->SetInt("door.openstate","1") Which doesn't look too bad. Of course, you could simple add a prefix to all your functions and attributes you don't want messed with, and achieve the same exact outcome with a lot less complexity: function entity:Door_Open() this:Turn(1,0,0) this.door_openstate=1 end

I don't know because it depends on what I am able to fit in before the release. If I predict too high, then people get upset because the things they read in my blog don't justify the price. If I say too low, then people get upset when the price turns out to be higher. There are still a lot of unknown things I am researching.

I've got iterators working, so you can do this: for child in entity.kids do Print(child.name) end Unfortunately, the Entity returned by the iterator does not match the lua object the main program uses, and so you can't set attributes from the main program and detect them elsewhere. This is pretty complex stuff.

With Luabind, it turns out we don't even need a table associated with an entity. We can just add values and functions straight to Lua's representation of that entity in the virtual machine! So instead of this: object.health=100 object.entity:SetPosition(1,2,3) You can just do this, which is much nicer!: entity.health=100 entity:SetPosition(1,2,3) So there's no object/actor nonsense, you just work directly with the entity itself. Entity KeysThe Get/SetKey convention from Leadwerks Engine 2 is going away, to be replaced with more direct entity access functions. You can still store "keys" with strings, but this will directly set the values of the entity table in Lua, so they can be access from script more easily: void Entity::SetString(const std::string& name, const std::string& value); std::string Entity::GetString(const std::string& name); void Entity::SetFloat(const std::string& name, const float& value); float Entity::GetFloat(const std::string& name); void Entity::SetInt(const std::string& name, const int& value); int Entity::GetInt(const std::string& name); void Entity::SetObject(const std::string& name, Object* o); Object* GetObject(const std::string& name); Here's a sample "mover" script that performs simple movement and rotation each frame: function entity:Start() self.movespeed=Vec3(0) self.turnspeed=Vec3(0) end function entity:Update() self:Move(self.movespeed) self:Turn(self.turnspeed) end And this is how we would set an entity up in C++ to turn 2 degrees on the Y axis each frame: Entity* box = CreateBox(); box->AttachScript("Scripts/Entity/Mover.lua") box->SetObject("turnspeed",Vec3(0,2,0)) Getters and SettersLuaBind does support getter and setter functions, and I decided it would be nice if we could have an object-oriented command set for the surface commands (even though vertices are NOT an object-oriented structure, at all!). If I can get vectors to be accessible in Lua, then we will be able to write code like this script, which performs a "breathing" effect on any model, ala Quake 3 Arena: function Entity:Start() this.speed = 1 this.amplitude = 0.1 end function Entity:Update() local n,v.d --Make sure this is a model entity before calling commands if this.class = CLASS_MODEL then --Get the distance the vertex should move d = math.sin(AppTime() * speed) * amplitude - amplitude --Apply movement to all vertices for n = 0,this.surface:length()-1 do for v = 0,this.surface[n].vertex:length()-1 do this.surface[n].vertex[v].position += d * this.surface[n].vertex[v].normal end end end end Multiple Script AttachmentsThis is a very tricky thing to handle, because the behavior is so hard to define. Right now I have it set up so predefined functions will be called, in order of their attachment. As for user-defined functions, that's a lot hard to pin down. If two scripts contain a function called "Kill()", and the script itself calls the function, should both functions be called? It will take more time and testing to see how this should work. A big problem is if the user defines a function that returns a value, and two scripts contain the same function. If another script calls the function, what should be returned? So then I start thinking about separate spaces for each script attachment, with their own set of members and functions, and I realized how incredibly hard to understand that would be, if you were accessing this entity from an outside script. In the absence of any compelling technological advantage, simple is best. For now, only the predefined functions get executed in sequence, and none of those return a value. My prediction is multiple script attachments will be used primarily by non-programmers who just want to combine a few behaviors and see results without touching any code. When you get into more complex behvior I think script programmers will generally use one script per entity that does what they want. It's still only 1:30 in the afternoon, so I am going to go get lunch and spend the rest of the day working bug reports. The model reloading issue that's active is a tough one. There's also a PHP issue uploading files to the site, so I will try to get that resolved.

Buying the beta gets you the finished 3.0 release.

I am guessing you have an ATI 5000 series GPU? There is a bug report in the tracker that is similar.

We use Lua. That isn't going to change.