[Pure³d - Realtime Viz Company]

Real estates should be real estate in English.

[LoadScene Callback]

Pretty easy for us to implement ourselves by creating our own scene loader. You'd probably be best served by loading the terrain/vegetation using the standard LoadScene command, then using your own loader to load the individual items one at a time so you could track status. At least it's a temporary solution until Josh adds this in, if he does.

[Change textures at runtime]

If you download the LETheora library I made (http://leadwerks.com/werkspace/index.php?app=downloads&showfile=89) there's a utility function for doing it to static meshes in the nio_util.lua file.

 

Here's the code for it:

 

function makeUniqueMesh(ent, meshname)
local orig_mesh = ent:FindChild(meshname)
local new_mesh = CreateMesh(ent)

for surface_index=1, orig_mesh:CountSurfaces() do
	local orig_surface = ent:FindChild(meshname):GetSurface(surface_index)
	local new_surface = CreateSurface(new_mesh)

	for i=1, orig_surface:CountVertices() do
		new_surface:AddVertex(orig_surface:GetVertexPosition(i-1), orig_surface:GetVertexNormal(i-1), orig_surface:GetVertexTexCoords(i-1,0))
	end

	for i=1, orig_surface:CountTriangles() do
		new_surface:AddTriangle(orig_surface:TriangleVertex(i-1, 0), orig_surface:TriangleVertex(i-1, 1), orig_surface:TriangleVertex(i-1, 2))
	end

	PaintSurface(new_surface, GetSurfaceMaterial(orig_surface))
end

new_mesh:SetPosition(orig_mesh:GetPosition(1),1)
new_mesh:SetRotation(orig_mesh:GetRotation(1),1)
HideEntity(orig_mesh)
UpdateMesh(new_mesh)

return new_mesh

end

 

You can use PaintEntity on the mesh it returns to change the texture. Again, you can only use it on non-bone animated meshes as we don't have access to the bone information to replicate it.

 

You could also use a special shader and a texture atlas that does a lookup based on the alpha channel. Take a look at this thread for the code:

http://leadwerks.com/werkspace/index.php?/topic/607-non-instancing-copy-command/page__hl__atlas__st__20

[Change textures at runtime]

Take a look at SetMaterialTexture (http://www.leadwerks.com/wiki/index.php?title=Materials#SetMaterialTexture)

 

This will change the texture for all instances of that model though. There's no way to change it for just one instance of the same model if it's animated. If it's a static model then you can duplicate the mesh, paint it and hide the original.

[SetParent() to remove parent]

Save the original parent in a variable and set it back before it exits? Maybe it's parented to scene or something.

[Real Sun]

I want a space monster truck! I could drive around and crush little bitty planets that get in my way.

[Issue with normal lighting]

I remember moose saying that you need to invert the green color (Y axis) in the normal map.

 

That did it! Thanks Loomja, I was pulling my hair out trying different combinations, swizzling, etc.

[Issue with normal lighting]

Just a bump to make sure Josh sees this

[DXT5nm and 3Dc DDS compression]

Did you see this post? This is what I'm talking about:

 

http://leadwerks.com/werkspace/index.php?/topic/1183-issue-with-normal-lighting/page__pid__10915__st__0entry10915

[AddBodyForce trying to get it to work...]

Try creating it in lua in the editor and turning on physics visualization so you can see what's going on.

[AddBodyForce trying to get it to work...]

You want both. You want the pushing force (Force) to move the object sideways, and the turning force (Torque) to rotate the body.

[AddBodyForce trying to get it to work...]

Force adds a pushing force, Torque adds a turning force.

[DXT5nm and 3Dc DDS compression]

K, tested, looks like it's an issue w/ LE. I don't really want to touch any other normal mapping shader code until this is resolved as I won't know which are problems with my code and which w/ LE's.

[Leadwerks User Guide - LUG]

Try http://leadwerks.com/werkspace/index.php?/page/resources?record=16

[AddBodyForce trying to get it to work...]

http://www.leadwerks.com/wiki/index.php?title=Bodies#AddBodyTorque

 

You can use CalcBodyOmega to help determine how much force you'd have to add, or just experiment a little bit.

[AddBodyForce trying to get it to work...]

If using physics you should exclusively use physics. Use physics to turn the cube instead of PointEntity. You can't really mix manual positioning and physics, they don't play well together.

[AddBodyForce trying to get it to work...]

http://www.leadwerks.com/wiki/index.php?title=Entities#TFormVector

[AddBodyForce trying to get it to work...]

According to the wiki what you have should work, but it seems that it's applying the force using the global coordinate system instead of the local. You could try switching the third parameter to 1 or using TFormVector to create the vector you want in global space and use that.

 

Oh, one other thing that might be an issue, if you are pointing the object and not the body then the body and model might be out of sync. So the body is still moving to its right, but the model is now facing a different direction.

[Issue with normal lighting]

When lighting normal mapped objects something is wrong. This is using the default diffuse bumpmap shader, tested in 2.3 and 2.31.

 

Notice that the lit side of the bumps changes as the cube rotates. This makes them look like bumps sometimes and holes at other times.

 

The camera is at roughly the same location as the light. The light you see in the background is an ambient light.

 

The same model and normal map in Unity doesn't exhibit this problem.

 

Demonstration:

 

http://vimeo.com/9433786

 

Anyone have any ideas?

[DXT5nm and 3Dc DDS compression]

Could you include an OBJ version of the cube? Something is a little funky w/ the direction of the lighting w/ normal maps in general. I want to test in a couple other engines and see if it's related to the model/normal map or the way LE handles them.

[DXT5nm and 3Dc DDS compression]

On the cubes, are they holes or bumps?

[DXT5nm and 3Dc DDS compression]

Instead of relying on articles I decided to do the math:

 

x*x + y*y + z*z = 1

 

z*z = 1 - x*x - y*y

 

z = sqrt(1-x*x-y*y)

 

So the way I have it is technically correct. Could differing coordinate systems require a change in this Josh?

[DXT5nm and 3Dc DDS compression]

Hmm, http://code.google.com/p/nvidia-texture-tools/wiki/NormalMapCompression and http://developer.nvidia.com/object/real-time-normal-map-dxt-compression.html have:

 

z = sqrt(1 - x*x - y*y)

 

I also found an article that states:

 

The Green and Alpha channels are used because in the DXT format they are compressed using somewhat higher bit depths than the Red and Blue channels. Red and Blue have to be filled with the same solid color because most DXT compressors use an algorithm that compares differences between the three color channels. If you try to store some kind of texture in Red and/or Blue (specular power, height map, etc.) then the compressor will create more compression artifacts because it has to compare all three channels.

 

So might be worth using a separate spec map, or supplying a shader that uses the alpha value from the diffuse instead of the normal for specular values.

[DXT5nm and 3Dc DDS compression]

It's quite possible it was just a typo. May account for some other issues I was seeing, thanks for catching this. I'll check it on my system and update the code above.

[DXT5nm and 3Dc DDS compression]

Here's the small addition to use the red channel instead of the alpha for the specular value.

 

In mesh.frag replace

 

	#ifdef LW_SPECULAR
		shininess = bumpcolor.a*specular;
	#endif

 

with

 

	#ifdef LW_SPECULAR
		#ifdef LW_DTX5NM
			shininess = bumpcolor.r*specular;
		#else
			shininess = bumpcolor.a*specular;//*fOcclusionShadow
		#endif
	#endif