2 bones per vertex, yes its in the vertex shader

they're in the codes, chr::create

Ah, only two, that's why I had errors with my mesh. Do you think this could be raised to maybe 4?

would 3 be ok? I don't want to overdo the vertex shaders computations

Yes, that would do it too (at least for that mesh).

I guess two would actually be reasonable for most situations, but I don't know how to say max to give only 2 bones influence on one vertex.

Is this (raising the weight influence count limit) something easy to do that won't slow down the engine notably or should I better go and optimize my mesh and make sure no vertexes are influenced by more than two bones?
However I do think that the third influence does make the mesh bend more smoothly...

Quote:I guess two would actually be reasonable for most situations, but I don't know how to say max to give only 2 bones influence on one vertex.

when importing mesh, and >2 influences are detected, then only 2 most significant are used.
adding 3rd influence, will take some time, I'll add this to my list

• How much can the color be controlled?
  Can we change the:
  • contrast
  • brightness
  • exposure
  • hue (shift)
  • saturation
  • color balance
    
  of the whole scene?
  

you can check bloom+hdr, and color transformations tutorial

Is there any way to change the size (gloss?) and color of the specular effect on the water (the "sun reflection")?

currently thats not implemented

How can I create a terrain from a 16-bit heightmap (in world editor)?

have you tried drag and dropping 16-bit gfx image to WE Import heightmap?

Problem is I have the height map as a 16bit photoshop grayscale image and the only formats I can export it to which are supported by the engine are dds and png.

DDS 16f export however doesn't work (the exporter says there is a bug or something), and png reduces it to 8 bit as it seems (if I create the terrain from that, it's very blocky).

This is the psd file: http://www.2shared.com/file/10855139/dd0efe94/ttt.html

---

Another question:
Is there any way I can bind a Flt* value to a slider control just like I can bind a Color* to a ColorPicker using ".autoData()"?
Then I wouldn't have to manually read out the data every update.

And again one of the old questions:

Quote:How do you determine if the window size has changed since the last update?

You said I should use D.screen_changed. But this is (according to documentation) only called "when screen proportions have changed".
I want to know when the absolute size (of pixels) has changed. Is there a callback function for that?
Or could you modify screen_changed to react to pure size changes even when the proportions stay the same?
Or does it already do that and the doc is misleading?

the next EE release should properly import 16-bit PNG when importing heightmaps

yes, you need to set autoData and point it to the same object that is given in fromGui or toGui

"How do you determine if the window size has changed since the last update?"
what window size?

screen_changed is used only when D.w() or D.h() has been changed

Quote:"How do you determine if the window size has changed since the last update?"
what window size?

screen_changed is used only when D.w() or D.h() has been changed

Yes I know, but D.w() and D.h() will stay the same when resizing from 640x480 to 800x600 because the proportions stay the same.
How do I find out if the window size in pixels changed? Is there a callback function for that or do I have to do the following

every update?

yes you can do that

you can also consider using D.scale instead of changing text scale
D.scale changes all components automatically