njord

Thanks a lot! AppLogMode is just what i needed

Hello everyone. As you know there are lots of messages that the LE engine prints out such as : "Loading texture "e:/workspace/iss/out/data/ig/leadwerksrenderer/materials/custom/clouds/cloud7.dds"..." etc. Is there any LE or C++ or Visual Studio way to disable these couts of engine.dll ? These messages really make it hard for us to see our own debug print outs. Thanks in advance.

I have looked at the materials of that gmf mate (LESDK 2.5\Models\Weapons\smg). There is nothing special in there, like disabling depth writing or testing.

We use LE engine as graphics renderer only. Our physics engine uses obj files (Nvidia Physx). So for debug purposes, loading and attaching the obj to a gmf greatly helps on runtime debugging.

Are you suggesting I should make it 1.0 m mate ? But inside the helicopter, i barely have 1m space for the pilot to sit. So if i make the near plane a large value like that, I wont be able to see the gauges buttons and joysticks in front of me, they will be clipped. I can scale the model up, there comes my Q1 above By the way : Right now my camera near clip is 0.35 and far clip is 500-1000-10000 - i tried different values. 0.35 is the highest value i can reach when DAYNIGHT script skybox is still visually bug free. If you change near plane to 0.40 lets' say, skybox cubic planes start to disappear. In other words, decreasing far clip plane did not help with jitter much i guess, but increasing near plane from 0.1ish values to 0.35 did help.

Hello again! We are creating a helicopter simulation as I told, so by modifying the near range, disabling SSAO and terrain shadows I have managed to reduce the precision loss problems to an acceptable level on a 30kmx30km terrain (1024x1024 resolution, 32m each tile length). Also by increasing the slope on the water-land intersection geometry, my waterplane flickering is reduced too. Thanks to Flexman However, as the project progressed, we have modelled a detailed helicopter, and when the pilot (camera) sits inside it, all the tiny buttons and gauges on the panel JITTER on far locations ! So I need further optimizations to further mitigate this problem. A dirty solution : I scaled up ONLY the helicopter by 5-10 times. From the point of view of the camera, everything seems properly scaled, but in fact, I am inside a giant helicopter and all the buttons and gauges are like 5 m away from me. Since they are both bigger and further, no problem in visual scale, unless you take a look from outside It is still not a problem, if i look from outside, i can scale back to normal size. However, when i land, or collide with an object, - since my collision geo is still small and it should stay that way, objects penetrate through the helicopter. To work around this, i need a special material that will render the helicopter over/after all other geometry. First of all , I want to ask you, how to make a "depthtest off" and "render last" material. As i have posted on another topic, I have managed to come up with a material like below : texture0="abstract::blackwhite.dds" color=1.0,1.0,1.0,1.0 depthmask=1 colormask=1 depthtest=0 castshadows=0 invisible=0 specular=0.5 gloss=0.5 bumpscale=0.5 zsort=1 cullface=1 overlay=0 blend=0 shader="abstract::mesh_diffuse.vert","abstract::mesh_diffuse.frag" depthtest=0 and zsort=1 : this makes the entity to be visible even when it is occluded by another object, great! However the entity is slightly transparent! If I make zsort=0, than entity is rendered last, even when it is actually in front of me. Q1. What is the proper way of "no depthtest & render last" == make something properly "always visible"? -------------------------- This is my quick and dirty solution of course, so I want to learn more about what you have gone through Flexman, if you don't mind Can you or anyone answer these questions also ? Q2.Converting LE source code into double is not easy right ? Also you couldn't "fully" do it as i understand, did it help a bit anyway? Do you recommend me to follow the same path by obtaining the source code and modifying? Q3."Modify shaders to add more depth bias based on distance from camera" == what do you mean by this, which shaders specifically, can u post a very simple example or give more insight to get me started ? Q4."User the material overlay flag where appropriate" it is used by decals as far as i know, to translate the decal surface a little bit closer to the camera. How can it help me ? Shall I write my "gauge, button, joystick" materials this way ? But, my problem with the helicopter cockpit surfaces is not flickering, it is the geometry degredation mostly. Vertices just move, its like they are not made of a solid matter Q5."Render the scene in layers and blend them" how can i do that, what is the reasoning behind it/how will it help ? Thank you very much for reading all this and noob questions if any Cheers! visuals : (On the second image, black and white cube is between terrain and helicopter. But as you see it is always fully visible even occluded. However, it is transparent as well. I dont want it to be.)

I can load ".obj" files in LE using C++ coding and this free library : http://www.kixor.net/dev/objloader/ . U need to loop over all faces, their vertices, normals, and materials, and create a geometry on the runtime. It is pretty easy to do i can post a simple code chunk if anyone wants to take a look.

In other words, I am asking how to show a gun in your hand properly, not penetrating other objects or walls, without any tricks like scaling/positioning, but by using "depthtest disabling" and "rendering last" ???

Maybe you have two identically named materials in your working directory. LE indeterministically indexes and uses only one of them - probably wrong one, although you correct the other material. The problem is obviously related to zsort = 1 in my opinion. Check if you have identically named resources under your working directory or registered abstract path. Use absolute paths instead of abstract:: .

I tried to do the same thing for a "Gizmo 3D" model, so that each entity would have colored local axis arrows attached to its pivot, showing its relative orientation and position. But of course, I wanted Gizmo to be always visible just like in the Editor. Disabling depthtest is not enough. You also have to force the material to be rendered "last". Zsort=1 forces the object to be rendered last, but also it sorts these kind of objects before drawing, and makes them transparent. I have tested with a lot of objects instanced, if u use Zsort=1, it decreases the performance way faster than a Zsort=0 mat due to sorting. Partial solution to your problem would be using a material like this : texture0="abstract::blackwhite.dds" color=1.0,1.0,1.0,1.0 depthmask=1 colormask=1 depthtest=0 castshadows=0 invisible=0 specular=0.5 gloss=0.5 bumpscale=0.5 zsort=1 cullface=0 overlay=0 blend=0 shader="abstract::mesh_diffuse.vert","abstract::mesh_diffuse.frag" But you will have a semi transparent mat. Any one knows how to fix that, I would be glad to know. My gizmos are transparent, i dont want them to be. I just want them to be always visible.

up+

Thank you very much for your long explanation Flexman. Indeed we are trying to create a terrain for a helicopter simulation too It should be 30x30 km so the furthest location from origin will be 15000,15000 (plus the chopper can elevate into sky like 5000 or 10000 meters). By turning off terrain shadows and ssao, also by adjusting camera planes to 0.35,7500 now we have a rather acceptable level of visual artifacts & bugs, spiced with proper DOF and fog. However, can you explain more about your advices below ? We will also try building simple models without intersecting polygons as you suggest. I will post how much it will help. PS: our terrain heightmap is 512x512x100m now (I modified 512x512x10m sbx to have a instead 100m resolution grid). This causes some small differences between the phy and gmf of the terrain. However since we use LE for only visualisation, it seems ok for us.

When fov was 51 degrees, I shortened my directional light shadow distance by changing multipler = 3 to 0.3 on the below code (simply made shadow distances 2.4m,12m,24m. They were 24m,120m,240m before.). This get rids of the "partially or fully disappearing shadow" bug. Of course , now there are shadows only up to 24 meters which is looking really bad with low fov. Another possible solution is increasing the FOV to 60+. But i need small field of view in my case. I will even use 45 degrees in the future. object.pivot = CreatePivot() object.light = CreateDirectionalLight() multiplier = 0.3 --was 3.0 before SetShadowDistance(object.light,8*multiplier,0) SetShadowDistance(object.light,40*multiplier,1) SetShadowDistance(object.light,80*multiplier,2) object.light:SetShadowmapSize(2048) multiplier = 2 SetShadowOffset(object.light,0.31*multiplier, 1.0, 0) SetShadowOffset(object.light,0.40*multiplier, 1.0, 1) SetShadowOffset(object.light,0.70*multiplier, 1.0, 2) SetShadowOffset(object.light,1.50*multiplier, 1.0, 3) PS: Josh, the shadows disappear on the borders of "directional light shadow stages".

Hi all. I encountered a strange problem with shadows, when field of view is small. When fov is 70 or 80 degrees there is no problem, but when I decrease it, lets say 50,55 degrees, shadow bugs (may) occur. First I thought it may be a problem related to our custom models or daynight script. But then I performed some tests on Editor and reproduced the bug. Create a terrain in editor. Drag atmoshpere and directional light. Drag in the monster truck (a little higher from the surface to see its shadow easily). Configure editor field of view to 51 degrees. Move back and forward in the direction of monster truck. You will see its shadow partially or fully disappearing based on camera distance and viewing angle. Strangely, one of our custom models, (airport bridges) do not produce the same shadow artifacts. Maybe it is related to pivot point ? Here are 2 video links showing monster truck with shadow bug, airport bridges without shadow bug : ftp://81.214.87.33/ port:21 username : katron pass : katron2012 filenames : FOV_SHADOW_PROBLEM.avi FOV_SHADOW_PROBLEM_2.avi Here is a screenshot for a quick glance:

Hello all guys! I have created the largest terrain possible in LE which is 4096x4096x10m (in fact, by modifying sbx with notepad, u can make it even larger). On distant locations (relative to origin), I see artifacts on shadow maps and UV assignments as well as geometry degredation which I believe all due to floating point precision loss. Here is the related video, although you can check it out yourself by creating a terrain in Editor. Parts of terrain at locations (0,0,0), (7500,0,7500), (15000,0,15000), (20480,0,20480). : ftp://81.214.87.33/ user : katron pass : katron2012 file : "LE 4096x10m map precision problem - DIVX.avi" What are your comments on this issue ? (One possible dirty solution : I can move the terrain and objects on it instead of moving the cam ) PS: I encountered precision problem on my previous job, where we were implementing a google earth clone 3D app. We were visualising the whole earth along with a tiny house or road sign in the same scene. We solved the issue by utilizing "camera relative rendering" & "using double precision math on vector calculations taking place on cpu" & "enabling consistent floating point mode on direct3D".

OS is Win7 32 bit . There is an sbx file and a lot of gmf's referenced in it. Gmf's and other related .mat .dds etc. files (1800+files) are in a single folder, under LE app working directory. GMF's fail to load, but app does not crash. I do not see any gmf's except LE terrain surface, vegetation layer, atmosphere. For testing, I copy a single gmf to .ModelsEntitiesEnvironmentAtmosphere. Surprisingly LE finds its mat and dds inside the big folder and loads it. However rest of the gmf's, stil not loaded. I copy whole app to a Win7 64 bit pc. Everything opens. OR I divide big folder into 4 folders in 32 bit pc, Everything opens.

What do you mean by ? How can users get this fix ? By downloading LE 2.5 again ?

Hello all, We have created a LE application that answers our needs, and exported (compiled) it as a "dll" rather than an "exe" executable. Our main simulation.exe loads "OurLeApp.dll" and uses it to visualize the simulation. Very rarely, on some computers and on some projects, LE "fails to load" the resources (mat,dds etc.) of some gmf's that are included in the sbx file (for example, City.sbx, inside of it there is a model referenced as abstract::hospital.gmf). Although it cannot open the gmf models on the sbx, it shows the vegetation layers and the terrain surface. Of course when I move the entire terrain which is the "sbx, dat, raw etc. files, and the models referenced" to "Maps folder" in LESDK everything works, no problems. Our folder system is like : (Bold font indicates files&folders copied from LESDK) out ..simulation.exe ..Scripts ..bin ....ig ......leadwerksrenderer ........OurLeApp.dll ........engine.dll ........other LE related dlls ........shaders.pak ..data ....ig ......leadwerksrenderer ........Materials ........Models ........Sound ........and other necessary folders from LESDK ....entities ......minibus ........minibus.gmf ........minibus.mat ........minibus.dds ........minibus.lua ......airplane ........airplane.gmf ........airplane.mat ........airplane.dds ........airplane.lua ....terrains ......city ........city.sbx ........citymodelfiles ..........hospital.gmf ..........hospital.mat ..........hospital.dds ..........hospital.lua ..........school.gmf ..........school.mat ..........school.dds ..........school.lua First of all my working directory is out. "simulation.exe" is inside the "out folder" and started from there. At the initialization step of "OurLeApp" I use RegisterAbstractPath("./data/ig/leadwerksrenderer"); //(relative folder paths to out folder) RegisterAbstractPath("./data/terrains"); to make sure engine.dll sees both default LE files (out/data/ig/leadwerksrenderer) and terrain models (out/data/terrains) files. I do not register ./data/entities because I add them with LoadModel() and use exact paths (not abstract path). Again, this system works perfectly, but 1 out of 50 times, on some computers models and related files referenced in sbx with abstract paths cannot be found by LE. You have any idea ? One more question : is using RegisterAbstractPath twice correct ? Edit: I have divided the 1800+ files (hospital & school gmf,dds,mat,etc.) of the terrain into 4 folders. And now sbx gets opened. PC is win32bit btw if it helps. Edit2: sbx only fails to load gmf's, since it cannot open gmf's, it never searches for related mats or dds' anyway.

Thank you for explaining your method Mike. You basically pave tiles in front of you using the tiles behind you, like a treadmill. But in our case, when we divide the airport, all the tiles are unique. Just look at our scenes in Editor (ftp). Check the .dds textures in the folder. Those big textures (tiles) are all paved around the airport, unless you want to put the lines as seperate polygons and get aliasing artifacts.

Ok the link is fixed. You can download our sample scenes again Red, what i understand that you tell us to put low res huge terrain, and keep a moving "treadmill" small grid-ed terrain (9 tiles) around cam at all times. But tell me, when we move, we need to see the ground passing beneath our feet. How are we going to do that if we keep the same tiles? If not, how are we gonna change them every time we move the cam? What we are doing is now actually parsing the huge terrain into square tiles (forming a quad tree). Where we needed details, we have divided the square tiles at a greater depth. There are 2 parameters for detail in this approach, grid tile size and texture size. Smaller the tile size and larger the texture size -> more details and vice versa. We have kept texture size always 4096x4096, so one parameter left to adjust. We just divided square tiles more and more when we needed details in a quad tree manner. Anyway, we already have a grid on our terrain, check out scene2 (if you cannot open it check scene3 it is low res version) on ftp link. But as you can see on the attachment3.rar of my previous post, we have texture memory problem. 1) Josh, i think we already did that, or did you mean something else ? 2) Josh, can you tell us about LOD's please ? All the textures in gmfs and their lods are loaded into LE and then transferred directly to GPU right ? So there is no point for us to use LOD's in our case since they would increase the GPU memory pressure even more? 3) What about terrain paging? If I can implement an algorithm that silently loads any gmf on the background, I could load & unload tile GMF's while moving on my grid. This way I would never have too many tiles (thus textures) loaded at the same time and won't fill my texture memory ever at all. But one problem, last time I checked LE didnt allow me to call "LoadModel()" from another thread other than the main thread. If I cannot load meshes on the background, surely comes the stalls and freezes

1) I attached two snapshots.: Scene 1.png : Scene 1 screenshot with lines as seperate polygons, there is aliasing. But low texture memory usage (small textures are tiled over huge terrain surfaces, lines are extra surfaces). Scene 2.png : Scene 2 screenshot with lines as textures (with mipmaps & filtering enabled), no aliasing. But high texture memory usage (since textures are unique now, they are not tiled as before). 2) What do you mean "cut" your lines into the runway ? Should we put the lines as seperate surfaces with different materials on the terrain surface? Is this the same thing you explained here ? : 2) When we create a LOD gmf with a smaller texture for each high resolution terrain tile gmf, GPU texture memory usage is increased even more which is the opposite of what we wanted. This means LE loads all the textures to the gpu. How can I reduce GPU texture mem usage , if LODs with smaller textures do not help me at all ? By the way both our original models and their LODs do not have normal/spec but only diffuse textures. 3) What do you mean by that ? When we create mipmaps, textures are enlarged so that several mipmap levels are additionally stored ? 4) I think the same. I downloaded this program which shows GPU memory usage : http://technet.microsoft.com/en-us/sysinternals/bb896653 . Here are its results on scenarios with increased texture usage : Attachment3.rar PS: I will fix ftp link asap. PS2: Any other solutions to the aliasing problem like texture blending or decals or anything on your mind, please share it. Attachment3.rar

Michael, we have tried that. Yes, there is no z fighting and no need for alpha. But there is still aliasing problem. What solves aliasing is generating a huge texture with mipmaps and using anisotropic filtering. In the case of a "compound object" the concrete surface and a line on it still has different textures, they dont have a "compound texture with mipmap". Red Ocktober, sorry the link was broken. I will fix it as soon as possible. By the way, since we probably hit the wall over texture memory usage, we have tried using LOD1 for all the tiles. All original tile gmf's have a 4096x4096 10mb texture. All LOD1 gmfs of these tiles have a 256x256 43KB texture. So, only tiles around us would have high res textures with LOD enabled, we thought we could have decrease the pressure on GPU ram. But it did not work, LE loads all original and LOD gmf textures to GPU right ? Then what is LOD for ? It does not help decrease GPU texture ram usage, but only decreases the amount of geometry passed on to GPU ?

Hello all. We had several somehow related topics but i will start over and upload 3 example scenes to make it clear. We are modelling an airport terrain (actually its just a big gmf(s), we are not using LE heightmap). As all airports, it has some lines on it for the pilots and vehicle drivers to drive with respect to. Initially we had modelled our terrain with trivial polygons and we added lines as seperate polygons over the large terrain surface. To overcome z fighting between the surface and the lines, line polygons are slightly elevated from the surface (lets say 5 cm). While moving on the terrain with a vehicle we look at these lines almost horizontally and as they do not have a thickness (lines are just polygons!) we had aliasing problem on lines. Unfortunately defferred LE antialiasing support was not enough for us at this point. Take a look at our first scene in LE editor. Move the cam very close to the surface. Observe the aliasing problem on lines To solve this problem, we have divided the large terrain into tiles. And for each square tile, we have created a detailed texture including both the terrain and lines. Getting rid of line polygons, we have converted the pixel aliasing problem into texture aliasing problem, where mipmaps and anisotropic filtering are nice solutions and present in LE. However, we could not use small textures with tiling option for grass or concrete anymore, because we needed also lines on them, we had to use much bigger textures. There are exactly 103 tiles on the uploaded scene 2 and each of them have the texture size of 4096x4096 (DXT5 with mipmaps). Each texture is 10923 KB which makes 1.07 GB of textures on the total just for terrain surface. At this point our aliasing problem of lines is solved. Everything seems good, no "stair" effect on lines, mipmaps just work fine. But as soon as we add buildings, LE refuses to open the model on my GTX470. Most probably we are exceeding the total texture memory. Uploaded scene 3 is the same with scene 2 except the texture sizes are 1024x1024 instead of 4096x4096. LE now opens up the same small textured terrain with buildings, there is no problem. First of all, I would appreciate any information regarding texture usage. How much texture, how big textures can we use in LE or any 3D application. How to determine this ? What happens if the texture sizes present in a scene exceed the total amount of gpu memory ? Are they paged on cpu ram, how ? Secondly, do you have any ideas how to solve our aliasing problem without hitting a wall ? What can we do about scene 2 ? Thanks in advance. IMPORTANT : move different scenes into the LE editor map folder one by one. They have similarly named resources. Dont let LE to pick one of several resources randomly. UPLOAD LINK : ftp://81.214.87.33/Scenes.rar username katron pass katronftp

I tried it now, modifiying particles.vert to my needs solves my problem. Thanks! =)

anyone ? tell me if i am not clear enough mates, thnx. by the way, we can try to help with mirror implementation if anyone needs mirrors in LE.