BrokenPillar

I recently started playing with painting terrain, and so downloaded the "LeadwerksTerrainTextures1" pack from the download section. It is a very well made texture pack with a great variety of types, and does a great job of maintaining a cohesive look across all of the textures. However, I noticed a couple of things that appeared odd to me and so I spent a little time over the last few days updating them to better suit my needs. First, the diffuse textures appear to be saved as DXT5, and so have a blank white alpha and are twice as big as they need to be. Re-opening and saving them as DXT1 reduced the file size of the textures in the pack by approx 23 MB. Second, the normal maps have a lot of dark pixels scattered across them: *edit* Third, the spec maps are too bright. I am used to seeing values similar to those in the terrain textures for materials like metal, etc. From my experience, things like dirt and stone should almost be black.*edit* Fourth, most of them appear to be fairly "flat". This is ok if that is your style choice, but for my purposes I want them to appear a little more dimensional, so I added some depth to them. Here are some comparisons of the textures before and after (sorry for the image sizes, they're animated gifs) Click on them to see the animation, which shows before and after shots: and some comparisons of them used in a very simple scene: Anyway, I have cleaned up these issues on all but a few. I am more than happy to upload them to the download section, but didn't want to step on Josh's toes if he doesn't want them there since the originals are his. If he is ok with them being there, and if anyone else wants them, I will upload them so anyone can use them that wants to. *edit* I finished updating them to my satisfaction, and fixed some things that were bothering me with my initial pass. I have updated the animated gifs above with the final textures. *edit*

did you try adding an Editable Poly modifier to the top of the stack, or converting it to one before exporting it?

The only issue I have come across while exporting anything a second time is that if you have modified or created a .mat file for the object and export it with the "Export Materials" setting checked it will overwrite your .mat file with one generated by the exporter. I always just make sure to back up my .mat file before re-exporting, and then I haven't had any problems.

I am using the vertex colors for AO and for basic color, but the textures add more detail than simple vertex color allows. I am also adding bump and spec with textures. The diffuse is mostly white, but does have some grunge detail and coloring to blend over the top of the flat colors you get with vertex color. It looks like this: There is a little more information on this here: http://leadwerks.com/werkspace/index.php?/topic/1326-vertex-baked-ao/

That sounds great, especially that gradients effect the sway shader too. Thanks for the test. I was still curious how exactly vertex color effects the color of the model because I was getting slightly different results than what you described. I am working on a house model where I am assigning the color of the different walls by vertex color (it also has AO baked into the vertex colors), and then having a single texture that is mostly white overlay that so that every room can be a different color without using multiple textures. Only I am getting both vertex color and the texture I assigned in the mat file multiplied together. Then I assigned the sway shader to it instead, and all the walls lost their vertex color (and started swaying). So apparently the sway shader is what is turning the vertex color off from effecting the color of the model, not having a texture assigned. Also, for the black roots I was referring to pure black as a contact shadow being too strong (if the vertex color was effecting the color making it look like a shadow), not as a weight for the sway shader, which you are correct that you wouldn't want them to be moving at all. But now I know that the color gets turned off when you have the sway shader assigned anyway, so it shouldn't be an issue.

I didn't know it did either until I learned how to bake AO into the vertex color and was happy to discover that it did. It might look ok in the case of grass due to the contact shadow with the ground (I still tend to think black would be too strong), but what about other objects that you would want to "pin" specific vertices with the sway shader, like drapes to their rods, or flags to their poles? The black definitely wouldn't look right in those cases. This is something I have been meaning to try and figure out how to do for a little while now and just haven't gotten around to doing it. Also, you can't give the roots a different material or the grass that is swaying will look severed or disconnected from the roots where the swaying verts meet the non swaying verts.

Won't this also cause the part of the model that you don't want to sway to appear black? Changing the vertex color effects the color of the model at that vertex and not just the shader attributes, right? Is there a way to tell the engine to use the vertex color for the shader only? I guess this would be easy enough to perform some tests on, but I am not at my LE dev computer so I thought I would ask.

++ from me. Having the same animations that are used by multiple characters stored in each .gmf is as wasteful as having textures that are used by multiple meshes stored in each .gmf would be. If this is possible, or can be made possible somehow, it would be very useful.

I'm not sure if this is the problem, but one thing I always do to avoid scale problems is to reset the objects scale to 100% before export (or there is an option in the exporter to do it for you). So for example, if you create a box and then scale it up uniformly by 200%, Max does this by retaining a scale value for that object of x=200, y=200, and z=200, but that information doesn't get exported. If you select your object, then right click the scale button it will show you what scale values the object has. Anything other than 100 in the x, y and z can give you problems. To reset it, select the object then click on the "Hierarchy" tab and then click the "Scale" button in the "Reset" roll out. You can do the same thing with the "Transform" value for rotation problems.

DXT5 should only be used for textures that you need an alpha channel for (diffuse with transparency, bump with the spec in the alpha, etc) otherwise you should use DXT1 (without 1 bit alpha). The only difference between DXT5 and DXT1 is the alpha channel information, so if you don't need an alpha DXT5 will just add a blank white one and double the file size of your texture. This thread has more info and links about the exact details of why: http://leadwerks.com/werkspace/index.php?/topic/1099-dds-compression-types/

I was able to put together a tutorial document over the weekend that explains the process. I don't make a lot of tutorials, so I apologize in advance if it is hard to follow or not very well explained. It is intended for 3DS Max users, but I suppose the basic idea would be possible in most major 3D modeling tools. It would probably just be about finding the interface tools to do it. Anyway, here it is: VertexBakedAO.pdf

I mean the terrain that the editor generates that is not a part of your model. If there is terrain inside of editor in the scene that you are viewing your model in, then it will be added to the total number of polygons being drawn in the statistics.

Did you check to see if you have a terrain mesh created? That will be included in your total polygon count and could account for a large portion of your extra poly count depending on the size and resolution. Also GPU instancing should be automatic if you export them out into unique pieces and then assemble them in the editor.

If you have a terrain mesh created then the poly count will include that in it's total. As far as the memory footprint goes, I think that stat is supposed to show you how much memory your meshes, textures, lights, etc, are taking (the stuff that would need to be loaded when you compile your game), not how much total memory the editor is using to allow you to edit and manipulate the scene. Kind of like how Max needs more memory to load an object to allow you to edit it than an engine needs for the same object because it doesn't need to be able to edit it. At least that is my understanding of it, someone else with better knowledge of what exactly each stat represents could probably give a better answer. The other thing is that it looks like you are not taking advantage of the point light optimizations Josh made in 3.1 (which is the most likely cause of your dismal frame rate. That is a lot of point lights). Make sure that all of your lights and meshes are set up correctly (static, dynamic, etc), and then you should only be showing shadow polys for moving objects or lights in your stats. Oh, and fantastic model. My compliments to your artist.

I'm not sure what you mean. Those images are already in the editor in real time, unless you are saying that it could be done procedurally in the engine at run time without pre-baking the information in a 3D modeling tool, which would be cool to see, but I suppose the trade off would be that the lighting calculation wouldn't be able to be as accurate or complex.

I'll try to post a better description/tutorial of the process in the next few days.

I edited my first post with a comparison that has no baked verts.

Sure. I'll post some images later tonight when I get a second.

I recently learned a new technique for applying AO to an object by baking it into the vertex color in 3DS Max, and was happy to discover that LE already supports it. The images I have posted below are in the editor and have no textures or materials applied to them, and they are not using any post processing shaders like SSAO. There is only an ambient light in the scene set at a value of one. All of the color and the AO are baked into the vertices. The idea is that now I can use higher res tileable textures, and not need a secondary texture/UV set for AO. This may already be a commonly used and known about technique, but hey, it's new to me so I thought I would share in case anyone else was interested in different ways to achieve AO. Here is the top right image again with all of the same settings in the editor, only without any Baked Verts: Here's a short video as well: My linkhttp://vimeo.com/9745532

Really nice work, although it looks like you may have to start a new blog thread entitled "Progressing"...

I don't think it is supposed to compress the UV coordinates. Higher tessellation should be used to add more geometry to help the road conform to more complex terrain, which this property does accomplish. I think the UV coordinates getting compressed is probably a bug.

The tessellation property for the road nodes causes texture coordinate to compress making them tile more. The higher the tessellation, the more compressed the coordinates get and the more frequent the texture will repeat. Try lowering the tessellation value and see if that fixes it for you.

Not sure if anyone has seen this yet, but apparently Activision just announced an Indie Game Competition. Here is the Gamasutra article: http://www.gamasutra.com/view/news/27299/DICE_2010_Kotick_Talks_Passion_For_Industry_Debuts_Indie_Contest.php and here are the rules that have been posted on Activision's website: http://www.activision.com/ROOT/media/sweepstakes/indie_game/Indie%20Game%20Competition%20FINAL%20-%20WEB.pdf The winner will probably have to sell their game's soul to the Game Producer Devil, but you never know...

I tried it out too and think it is a huge improvement over the previous SSAO. Michael, it looks to me like you are making adjustments in the wrong section of code. I think the section to change settings to get better quality is this section: #define raycasts 4//Increase for better quality #define raysegments 6//Increase for better quality #define aoscatter 1.0 float raylength = 0.5;//*dist*1.0*50.0; float cdm = 1.0;// * dist * 50.0; Is that right Josh? I can get better results by changing those values, although it is really easy to get beyond the capabilities of my computer (which I would expect when playing with things like number of ray casts). Base on my initial testing, it seemed that reducing the aoscatter value seemed to help with the graininess with the least amount of impact on performance. I do see the slim white line around objects sometimes. It appears to be where the edge of an object meets the SSAO shadows. I am guessing this is where the shader is trying to figure out where to start occluding the effect so that it doesn't lay on top of the object, right? So basically you are seeing SSAO shadow being cast on the ground/wall, then a pixel width of no SSAO shadow where it starts occluding the effect to not lay on top of the barrel. I think this would give the appearance of a glow or white line.

One other option is to still use the blue for the z information (the blue channel is unused with the current code). Here a few options that would only require minor tweaks to the code you posted: 1. Store the normal map in the Green (y), Blue (z) and Alpha (x). Store the Spec Map in the Red (the Spec map gets compressed pretty bad this way, but it didn't seem to make a noticeable difference in my tests). This option would take the exact same amount of texture memory as the current method, not need the extra square root function Josh was worried about, and still gives results much closer to using uncompressed normal maps. 2. Store the normal in the Green (y), and Alpha (x), and derive the Z value using the math function (still need to figure out what is going on with the + or -). Store the Spec in the Red. This method gives similar results as option 1. 3. Do the normal map the same as option 1 or 2, but store the Spec Map in a separate texture or the alpha of the diffuse texture (for diffuse textures without transparency). This would increase the required texture memory by the size of the Spec Map, but would eliminate the Spec Map compression artifacts that come with storing it in the Red channel. It would also help with the problem described in your earlier post about storing different information in each channel (although the difference between storing all three channels the same vs having them different was negligible in my tests).