[Is there an easy way to set a "self.target" within a script automatically to player"?]

i do not want to drag the player into the affiliated fiel in the script entity, i want to do this code wise.

Can I ask why?

[How to pass variables between scripts? (Lua)]

Well, once you get the handle to that entity in a script, you can access its own script and do whatever you want. The most direct way to do this is use a script where one of the fields is another entity.

[WORLD MACHINE!]

I use L3DT to generate heightmaps. You might try it out.

[Collision without physics?]

Your call to SetRotation() is resetting the entity physics each frame, and it's also called in UpdateWorld() instead of UpdatePhysics(), where it should be (if at all): I changed the command to PhysicsSetRotation() which will do the same thing by applying torque to the object.

local window = Window:GetCurrent()

 

local onGround = false

 

function Script:Start()

x = self.entity.position.x

y = self.entity.position.y

z = self.entity.position.z

end

 

function Script:UpdatePhysics()

 

window = Window:GetCurrent()

 

if window:KeyDown(Key.D) and not cRight then

self.entity:SetVelocity(Vec3(10, self.entity:GetVelocity().y, 0))

elseif window:KeyDown(Key.A) and not cLeft then

self.entity:SetVelocity(Vec3(-10, self.entity:GetVelocity().y, 0))

end

 

if window:KeyDown(Key.W) and onGround then

self.entity:AddForce(0,500,0,true)

end

 

--self.entity:SetRotation(0, 0, 0)

self.entity:PhysicsSetRotation(0, 0, 0)

self.entity.position.z = -6.0

 

onGround = false

end

 

function Script:Collision( entity, position, normal, speed )

 

--print(normal.y)

 

if normal.y > 0.0 then

onGround = true

end

 

end

 

You will always have problems if you try to make a rigid body behave like a character controller, because a character controller is fundamentally unrealistic...it always points straight up and down and can't rotate around the XZ axes. Even if you use a force to try to change the orientation, that force will have other unintended effects.

 

The character controller is specifically designed for this type of movement and should really be used here. There are previous projects that used it in this way.

[Transparent textures don't receive light, and cast shadows.]

Two new shaders have been added in the beta branch on Steam:

"Shaders\Models\diffuse+normal+specular+alphamask.shader"

"Shaders\Models\Shadow\shadow+alphamask.shader"

 

These are untested, so opt-in to the beta at your own risk.

[Shader and Material in same folder]

Fixed. Update will come today.

[Rule of the thumb: Polygons for Models/Character]

Nice looking model. He'd be great for a main character. If you have a lot of those running around onscreen, you will want a low-res version. If you have a lot of point lights models like that could quickly raise the render polycount up to half a million, so be careful with those.

 

Fortunately, the engine uses GPU skinning, so the animated vertex count isn't much of an issue.

[Shader and Material in same folder]

Thank you. I have a pretty good guess why this is.

[Downloads from the Workshop]

All members have access to it. The Leadwerks 2 items are only for people with "Developer" accounts, because there's a lot of stuff that's incompatible with Leadwerks 3.

 

We're working to integrate Steam Workshop into Leadwerks, at which point that will provide a better way to share files, and you'll be able to publish your content directly to Steam.

[Alpha problem with terrain on editor startup]

It makes sense now. The texture wasn't being bound in slot 4 during the shadow pass. It only occurred when a terrain was present because terrain uses all 16 slots. In other cases, the texture was just left in slot 4 when it was bound during the main pass, and no other texture was ever bound there.

 

Expect an update this weekend in the beta branch.

[Transparent textures don't receive light, and cast shadows.]

Okay, I see it now. I think we can add this shader as an official one, let me look into it more closely. Your scene looks really nice, BTW.

[Alpha problem with terrain on editor startup]

Your directional light seems to cause some weird artifacts...I deleted yours, then created another one, and everything was fine. Ah, it was because it was scaled for some reason.

 

Regarding the shadow problem, it appears that the texture is not being bound in the shadow pass. Let me look into this deeper.

[Crash on ForEachVisibleEntityDo when entity is too far away!?]

Okay, that was easy to fix. It was a problem with the ForEachVisible... command. Expect an update this weekend.

[Crash on ForEachVisibleEntityDo when entity is too far away!?]

It has something to do with occlusion queries and context switching...let me see...

[Transparent textures don't receive light, and cast shadows.]

I don't see anything abnormal in that screenshot? If you turn on antialiasing they will look nicer, but I don't see anything wrong with it.

[Level of Detail support?]

The other reason for this is that I want to implement something more optimal than just switching objects. I want to be able to go into the model editor and tag different surfaces and bones to only render and animate at a certain LOD level. That way you just keep one entity, and all your logic stays the same for it, and it contains all the LOD information for optimal performance. This is a lot better than swapping entities like we did in Leadwerks 2, and it makes life a lot easier for the programmer.

[Steam upgrade for Leadwerks?]

Yep, it doesn't look like this will be a problem at all, and there is demand for it, so we will make this available when it's ready.

[Question About Optimisation]

Use the "caulk" material and those faces will be discarded when the map is loaded.

[Level of Detail support?]

LOD would certainly provide some savings in the example you mentioned, but that isn't typical of all games. I would expect this to be added some time this year, and in the meantime it's pretty straightforward to implement your own.

[Swap Out Newton]

You'll need the standard edition, but yes, the physics module is an abstract class that can be replaced with your own set of classes. As long as the required functions are there, the rest of the engine won't know the difference.

[Setting up SVN on Ubuntu 12.04]

And if you want a client, SmartSVN is very nice.

[Level of Detail support?]

We don't bother with it at this time.

• For most objects, saving a couple thousand polygons makes absolutely no difference in rendering speed, because the vertex pipeline is not the bottleneck.
  
• It increases the demands on the art pipeline.
  
• Tessellation can be used to automate much of this on the GPU.
  

 

Now when I start adding features that improve large outdoor scenes, it will make sense then because of the scale of the scene. But in most cases, LOD is a somewhat antiquated design idea based around how the hardware used to work. One exception is animated characters, which can still benefit from this mainly due to having a lower number of bones to update during animation.

[Old Project Problem]

Nvidia released a driver a couple years ago that caused this problem. There was a simple shader fix for it, I think it was in 2.5. You could probably just copy the bloom or HDR shader into your project...it was one of those, I forget which.

 

Search for "snow" and you'll find the thread we talked about this in. Or just use the latest 2.x version, which fixed this issue.

[Physically Based Rendering (+Material Layering)]

I think we'll continue to see cg and real-time graphics converge like this.

[Leadwerks Indie Edition- Windows Exception]

Another consideration is that the user might only need to update their drivers, but if they try a test that says they can't run it, they get turned away. Since I can't provide an accurate measurement for the end user, my response is to just leave it alone and let them decide.