Use uncompressed RGBA8 for textures that need really good color resolution. This mainly means GUI elements, but occasionally you'll have a texture for something else where the additional detail is worth the additional filesize.
Use DXT1 for textures where some loss in color resolution is acceptable and you don't need a full alpha channel. Note that DXT1 textures can still have transparent pixels, but it's only 1-bit alpha, i.e. each pixel is either completely transparent or completely opaque. This is what you'll use for most of your 3D textures.
Use DXT5 for textures where some loss in color resolution is acceptable and you do need a full alpha channel. You'll use this for any texture that needs partially transparent pixels. In particular, you'll want to use it for your normal maps (that's why the normal maps use the green and alpha channel; those are the channels with the best color resolution in DXT5). Using DXT5 for textures without alpha is pointless because in that case it's just like DXT1 except bigger.
Although Grimrock will load DXT3 textures without complaining, it doesn't seem to interpret their alpha channel correctly, so they are of little to no use.
All DXT-compressed textures should have dimensions that are multiples of 8. So 512x256 is okay, but 512x254 is not. Uncompressed textures can be of any dimension you like.
A DXT1 image is 1/8 as large as an uncompressed RGBA8 image of the same size. A DXT5 image is 1/4 as large as an uncompressed RGBA8 image of the same size. This is the motivation for compressing textures; they use less RAM* and less video RAM, and will also use less disk space.
*In the Windows versions of Grimrock 1 and 2, textures are stored in both main memory and your graphics card's memory due to (stupid) restrictions in Direct3D 9. The non-Windows versions use OpenGL for rendering and only store the textures on your graphics card.
kelly1111 wrote:---- is this possible: I am using my diffuse texture at the size of 2048 * 2048 and the spec and normal at 1024*1024 <-- is this good or bad practice ... to reduce file size ?
It is possible. Occasionally I'll have a model that requires very high detail in the normal map, and end up making the normal map larger than the diffuse and specular maps. However, I can't think of many realistic situations where you'd want the normal map to be smaller than the diffuse map, or the diffuse and specular maps to be different sizes.
Grimrock has a standard of 1024 pixels per 3 meters (each tile is 3x3 meters) for its texel resolution. But that obviously can't be obeyed perfectly since models have all sorts of different shapes and different distances from the camera (walls are going to be really close, ceilings not so much). Just stay reasonably
close to it and your textures will look consistent with the existing ones in the game.
kelly1111 wrote:But the rocks also stick out the backside (the side that wont be shown in the game) , does this method hurt performance (will the engine still render the parts that are not visible)
So, this is probably going to sound stupid: the renderer mostly doesn't know what's visible.
Basically, for each model on the level, the engine decides whether it needs to render it or not. Every model has a bounding box. Typically, this is the smallest box that can contain the entire model. Models with animations may need custom bounding boxes because the automatically computed one doesn't take the animation into account - see the definition of forest_oak_cluster for an example. The debugDraw feature on ModelComponent draws the bounding box for the model.
If that
entire bounding box is outside of the camera's field of view, the engine will not render that model. But if even a tiny piece of that box
is in the field of view of the camera, that model will be kept.
So this gets rid of all the models that the player isn't looking at, but it still kept all the models that are blocked from view by other models - such as whatever's behind a wall, floor, ceiling, etc. This is where OccluderComponent comes in. If a model is completely obstructed by occluder triangles, i.e. no line can be drawn from the camera to the model's (or light's) bounding box without passing through an occluder triangle that is facing the camera, then that model won't be rendered. Again, it's all or nothing: if most of a model is occluded but there's a tiny bit that isn't, the entire model is going to get drawn. So it's important to put occluders on your walls, floors, ceilings, and any other big solid things, and it's important to make sure that your occluders don't have gaps in them because the aforementioned all-or-nothing behavior means that even a small gap could make the whole thing ineffective.
Note that occluders aren't free - the more triangles your occluder models have, and the more surface area your occluder models have, the more work the CPU has to do. So don't put 200 meter tall occluder models on your walls, and don't use excessively complex geometry in your occluders. Look at the occluder models in the asset pack to get an idea of what they should typically look like.
So, yes, the engine will still render things that aren't visible, and your job is to help it do less of that.
Fun trivia: The OpenGL renderer is a bit smarter than the Direct3D one: if a model is partially outside of the camera's field of view, only the triangles inside the view will be drawn. The Direct3D renderer draws the entire model every time. This
only applies to the camera culling, not the OccluderComponent culling, so it rarely results in a noticeable performance improvement.
kelly1111 wrote:Another question: Is it possible to dynamically change textures ingame via a script? what i mean is for instance is the following. I have a set of mushrooms that I want to glow (emissive texture) but not al the time. could I turn the emissive texture part on and of in the materials section. Or is there another simpeler way to do this?
You can make two different materials that use the same textures except for the emissive map, then switch between the two materials with the ModelComponent:setMaterial() or ModelComponent:setMaterialOverrides() methods.
kelly1111 wrote:This one is a long shot I guess. I found a generate ivy pluggin for blender. It generates very good looking ivy on the surface the mouse pointer is at. I used it on a dungeon wall model. It creates a thing called a "curve" , I cant seem to export the model, blender crashes and the file size is 0. Does anyone have any idea what went wrong? I tried turning the curve into a mesh. But the same problem still occurs.
Is it becouse I havent assigned textures to the model in the model hierarchy?
You need to turn it into a mesh
and you need to make all the faces of the mesh into triangles and/or quadrilaterals. (The plugin will automatically turn quads into triangles when you export, but not polygons with more than 4 sides).
Also, you probably know this already, but be careful when converting curves to meshes because it's really easy to end up with ridiculously high triangle counts that way.
)