Jump to content

remi666

Members
  • Posts

    4
  • Joined

  • Last visited

Everything posted by remi666

  1. Hello Josh, hello everybody, I come back on a well-known topic: texture baking (or lightmap) Well, I posted one or two years ago on that topic, and someone (very kind) proposed me a shader, which multiplied the diffuse texture with the baked one. Here is an extract of the _mesh.frag related to this shader, inserted in the Bloom shader: //Bloom #ifdef LW_BLOOM vec4 bloomcolor = texture2D(LW_BLOOM,texcoord) * fragcolor; gl_FragData[3] = bloomcolor; gl_FragData[3].w = 0; #else #ifdef LW_GIMAP vec4 gicolor = texture2D(LW_GIMAP,vec2(texcoord1.x,texcoord1.y)); gicolor *= diffuse; gicolor.w = 1.0; gl_FragData[3] = gicolor; #else The issue with that algo, is that we do not have exactly the same result with the real-time engine as the “non-realtime”rendering engine (for example mental ray,…). I searched a lot by myself, and on the Internet. The fact is, when you combine linearly both maps, you will never get the exact result (Example: if you try diffuse*Baked or diffuse+baked, or diffuse*Baked+y*diffuse, etc…) Here is an example of this, with some pictures (based on a forum post on the game engine “Nova”): With the “classic algo” Diffuse Map*BakedMap (too dark result): cf doc file attached... With the algo Diffuse Map+BakedMap (too bright result): cf doc file attached... What we would like: cf doc file attached... The proposed algo, which is only an approximation of the wanted result, is the following: 1) For each pixel of Baked Map, convert the value RGB as HSL, and test the V value. 2) If V > 0,5 (in fact, this value can be modified…), perform DiffuseMap+BakedMap for that pixel 3) If V < 0,5 (in fact, this value can be modified…), perform DiffuseMap*BakedMap for that pixel Well, as I know nothing about shader coding, I hope that someone could help me to code this shader, which will be probably very useful for many people. Thanks in advance PS: And for those who will ask "why don't you use deferred rendering ?", I will say "try to dvelop a video game, with IA, Navmesh,...And you will know why ;-)..TO SAVE FRAMES PER SECONDS !!! Baking_00.doc
  2. Hello Leadwerks team, I have posted my issue in the bug tracker, but I have no news... Somebody could investigate, because this issue has some impacts on the performances of our game ? thanks a lot, Remi
  3. Hello Lummoja, I do not understand why you mention that "LE 2.3 has also only frustum culling, but no occlusion culling.". To me, LE 2.3 has both, and I posted an example in the bug tracker, where you see a discrepancy of the framerate and polys computed with a gmf file using the occlusion culling (enabled) Remi
  4. Hello everybody, We have noticed a strange behavior of Leadwerks in the 2.4 versus the 2.3 concerning the occlusion culling: On 2.3 version, when we checked the "occlusion culling" option in LE on imported objects, we noticed a higher framerate when the object was behind other objects (because it was killed by the GPU with the occlusion culling algo I guess). Now, with the 2.4, it does not work. You will find attached an exemple: if you stay in front of the cube (with all the sphere behind): - you will see in 2.3 version around 1000 polys if occlusion culling is enabled - you will see in 2.3 version around 20.000 polys if occlusion culling is disabled - you will see in 2.4 version around 20.000 polys whatever the occlusion culling status Nota: to have the Properties menu of an object, I add the following scipt in LE 2.4 for this object: require("scripts/class") local class=CreateClass(...) ...and in "Appearance", I check "occlusion culling". The same behavior has been observed by compiling an other scene, by using LE 2.3 C libraries versus LE 2.4 C libraries.... thanks in advance for a quick answer occlusioncullingtest.rar
×
×
  • Create New...