Niosop

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

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.

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.

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

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.

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?

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.

On the cubes, are they holes or bumps?

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?

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: 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.

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.

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

Nice examples. Could you take the guy model and add in a non-compressed version as well so we can see how close DXT5nm comes to the original? I'll add in spec to the red channel, although getting it there in your texture editing program might be a pain. I'll think a bit on the best way to handle that.

There are probably plenty of coders around here that would trade code for assets or be willing to team up on a project.

Try going closer to the terrain when you try and place the object. Objects will only place up to a certain distance. Not sure if this is the problem or not, but it's one thing to try.

I updated the code to use .ag instead of .ga. I originally used .ga because it made my test model look a little better, but I think it's because my model had some issues. Feel free to try both versions out and see what you come up w/. Yet another page showing decent pictures of the different methods in use: http://www.ozone3d.net/tutorials/bump_map_compression.php

Another option is A8L8 (GL_HILO8_NV). It's not compressed, but since it uses only two 8-bit channels then you can get the same quality as an uncompressed RGB8 texture in 2/3's the space. You'd still have to calculate the Z component which requires use of sqrt, but hey, 1/3 off w/ no quality loss. I think 3Dc is the best option if it could be supported, as you get 4:1 compression w/ very little quality loss and it's hardware accelerated.

Just for resolution. I think it's 5658, so by using the two highest precision channels and calculating the Z then you can squeeze a little more precision out of it (8/6/calculated Z). Whether it actually makes a noticeable difference in either visual quality or FPS I'll leave it to BrokenPillar to do the comparisons and let us know what he comes up with. We could stick specular and something else in the R and B channels if we wanted, there are two 5 bit channels left over. Auto detecting the format in the shader isn't working out very well so I'll leave it as a define so that people who want to use it can.

Cool then. Can get rid of all the defines and such and just detect if r and b values are 1, and if so assume it's a DXT5nm and do the swizzling. Will update it now and see how well it works out.

I think she means setting up your movement/action keys. She wants to display the currently assigned key in the menu and have it look super handsome (like me). Maybe take a picture of your keyboard and just cut the keys out? As long as your keyboard is cleaner than mine....or if you're doing a post apocalyptic type game then you could use my keyboard.

Find a nice font...

K, it seems to be working. One question: I've heard that "if" statements in fragment shaders are expensive. Would it be worth detecting if a normal map is in DXT5nm format (R and B channels should equal 1) and automatically switching, or would the 2 if statements slow it down enough that it's worth having a different shader define (LW_DXT5NM) and require the user to make a diffuse_bumpmap_swizzle.frag shader? If anyone wants to try it out, here's the updated portion of mesh.frag: #ifdef LW_BUMPMAP #ifdef LW_TERRAINNORMALS //Use terrain normals terraincoord=vec2(vertexposition.x,-vertexposition.z) / terrainsize + 0.5; terrainresolution = terrainsize / terrainscale.x; terraincoord += 0.5 / terrainresolution; vec3 worldNormal = ((texture2D(texture14,terraincoord).xyz - 0.5) * 2.0).xyz; normal = normalize(gl_NormalMatrix*worldNormal); #else vec4 bumpcolor = texture2D(LW_BUMPMAP,texcoord); #ifdef LW_DXT5NM normal = bumpcolor.xyz; normal.xy = bumpcolor.ag * 2.0 - 1.0; normal.z = sqrt(1.0 - normal.x * normal.x - normal.y * normal.y); #else normal = bumpcolor.xyz * 2.0 - 1.0; #endif #endif #ifdef LW_DETAIL normal += texture2D(LW_DETAIL,texcoord * 4.0).xyz * 2.0 - 1.0; #endif normal.z /= bumpscale; normal = T * normal.x + B * normal.y + N * normal.z; normal = normalize(normal); #ifdef LW_SPECULAR shininess = bumpcolor.a*specular;//*fOcclusionShadow #endif #ifdef LW_SPECULARMAP shininess = texture2D(LW_SPECULARMAP,texcoord).x*specular;//*fOcclusionShadow #endif #else normal=normalize(normal); #endif It's used something like this: diffuse_bumpmap_swizzle.frag #define LW_DIFFUSE texture0 #define LW_BUMPMAP texture1 #define LW_DXT5NM Include "mesh.frag"

Just because of typecasting. If you multiply/divide a float by an int I think the result is cast to an int. I usually forget the casting rules, but in general it's a good idea to cast everything to the highest precision type you want to use before performing math operations on them.

Yeah, you're right, in C/C++ it would.

I'll add in a DXT5nm shader snippet (almost done w/ it, just need to test/debug). For 3Dc I think it would need engine support to work fluidly w/ everything else. We can add our own test support by manually creating the texture and loading the data, but it wouldn't be automatically loaded by the engine's texture loading stuff, so it's not optimal.