lightmap and texture together ?
Community Forums/General Help/lightmap and texture together ?
| ||
| i dunno if this is possible but : is it possible to become one file for both ? i mean can i precalculate texture & lightmap to get one file ? thx |
| ||
| If you mean blending them, that would be possible, but then the 'detail' texture would have a pretty low res. Alternatively, the total texture should have a huge resolution. I don't think any of those is advisable. I think the main reason for this separate lightmap/detailmap method to exist is to maintain some resolution on your models. But you could maybe tile the two, place them side by side on a single texture. Then adjust the UV coords so: UV0 = UV0 * 0.5 UV1 = UV1 * 0.5 + 0.5 Where UV0 is the first set of coords, and UV1 is the second one. |
| ||
| The other reason is that every 'tile' of normal texture would end up being different to the previous one (because of the varying shadows), and would require huge amounts of VRAM. It is possible tho. You can do it in 3DSMax and in gile[s] (v1 only possibly). |
| ||
| As mentioned, possible yes, advisable no. You can't recycle the underlying texture as every vert is going to need it's own to get the shadow right = CRAZY extra memory used. You have to do this for the shadow texture anyway BUT if they're separated they can be independent resolutions so you could use a 256x256 for your actual texture and then have lots of room for a shadow texture, or just accept that the shadow might have blocky edges (probably a mix of the 2). More control and lower overhead = win win over pre-baking everything together. |
| ||
| Perhaps the question should be "why do you want to do it?" It may be that you're trying to achieve something which could be done another way. Or it may be that you have very specific requirements and perhaps it is advisable - in this very limited circumstance - to bake the texture and lightmap into one. |
| ||
| Ok thanks for your answers . Its not a Problem ,much moore a Theoretical Question. Last edited 2011 |
| ||
| Is there a way of baking light, on-the-fly, that is, creating a simple light map when a new level is started? Pre-baking does not take into account scenery getting moved around only at the initial level load? |
| ||
| If you wrote your own shadow system, you could logically then use that to generate baked textures, etc... it would be a helluva lot of work though I suspect. IMO you'd be better off creating a solid dynamic shadow system than a dynamic shadow system designed for texture generation... seems like 120% of the effort for 80% of the returns... |
| ||
| Thanks for the reply, what is a "solid dynamic shadow system"? |
| ||
| solid, dynamic shadow system. damn you english language! basically a real-world usable, stable system by which you can generate shadows "dynamically" (e.g. based on the current state of the world space and lighting conditions.) IMO if you can get that far, then going the extra mile to be able to generate "baked" textures, and then applying those would be a LOT more work than just optimizing the shadow system to run in real time (so the textures don't need to be baked at all and it would be live so moving a light source or object would adjust the shadows as well). A lot more work to get NON real-time shadows. |
| ||
| Ah I see. Using on-the-fly baked shadows has the advantage of speed, for shadowing static objects placed when your level is initialised. I was hoping to write a procedurally generated level routine but I can't use offline baked shadows with that kind of level data. Dynamic shadows are easier, relatively speaking but the speed impact can be a real burden, especially on older systems/mobile devices. |
| ||
| If your level is created using prefab elements (boxes, piramids, ramps etc.) and there is only a single directional light, maybe you could compound a lightmap using prerendered patches? |
| ||
| There's a thought... still could be a hassle to map correctly but every bit of complexity you remove from the equation makes it that much easier to solve... |
| ||
| If you have a single directional light (sun, for instance), you could try stencil shadows. You wouldn't need to calculate the extrusion every frame (just once, at load-time), and dynamic objects would get shadowed when going under the environment's shadows. It would look pretty good. |
| ||
| Downloading giles (v1) ,but cant find the option to blending texture and lightmap together . Beaker ? |
| ||
| How could you extract the required UV information from the stencil map, say if I was using OpenGL? |
| ||
| How could you extract the required UV information from the stencil map, say if I was using OpenGL? |
| ||
| You don't extract UV information from the stencil map to do stencil shadows. You first render the whole scene with ambient light, then "mark" the stencil buffer by rendering the shadow volumes and then re-render the whole scene with direct lighting and stencil culling turned on (without clearing the color buffer of course). Only parts that the shadow volumes don't hit will be rendered with the light influence - thus making those parts brighter and shadowed parts remain dark [or ambient-lit, if you will]. It's a multipass process. There are a few ways to go about stencil-shadowing with shadow volumes in OpenGL (some even patented, like the Z-Fail method). The method used for rendering has to change if the camera intersects any of the shadow volumes, or else holes in the shadows will appear. http://joshbeam.com/articles/stenciled_shadow_volumes_in_opengl/ http://www.codesampler.com/oglsrc/oglsrc_8.htm#ogl_shadow_volume |
| ||
| Thanks for that but I wanted a way to 'quck bake' shadows onto a texture (or multi texture) at the level load event. The lights would be static. Icant use a pre-bake method as parts of the level may change, inter level loads. Speed is what is required at the fist of flexibility. I have to keep to a single pass rendering tequnique for the target platforms. |
| ||
| I didn't get that. If you are baking the lightmap at load-time then that's pre-baking it. In any case, you can use a unified system of CSM* or PSSM* for real-time, dynamic shadows for everything (environment, characters, objects etc.). *Cascaded Shadow-Maps **Parallel-split Shadow-Maps (it's a type of CSM) Last edited 2011 |
| ||
| Thanks for that (and damn the iPads rubbish autocorrect! :P). It's an interesting subject, the more I look into shadow systems in general, the more intriguing I am finding the subject. |
| ||
| Won't your texture usage go through the roof blending the lightmaps onto the texture. It pretty much makes tiling textures unusable, so instead you'll have to have one very very large texture for these areas. That is why the whole idea of using a different UV set exists for lightmaps. I can't imagine this being a useful idea in any way, shape or form. I am very curious what you'd use it for ? :) |
| ||
| Mulititexture would be used if texture memory was getting squeezed, shadows using a smaller format, 2 bits for example in this situation, texture compression can be brought in to help. It's all about speed, if the engine runs out of resources or extra resources are available it changes the method it is using to render the scene. Adapting to maximise the rendering speed is the main goal, while sacrificing as much texture memory to do this as possible. I have tried various methods of shadows, most require at least two passes, some fast hardware or advanced graphics features, shaders for example. Or pre bake, which locks all your geometry into one position. I'm looking for a halfway house, semi static and it needs to work on slow hardware, if possible. My game is 3D puzzler, set from a first person perspective. The puzzles are mainly logic ones but some are physics based. The basic level structures are predesigned with procedural methods used to alter the level design and certain puzzle elements. I really want a decent look to it and for it to make it onto the mobile Market without crawling. Last edited 2011 |
| ||
| Mulititexture would be used if texture memory was getting squeezed, shadows using a smaller format, 2 bits for example in this situation, texture compression can be brought in to help. It's all about speed, if the engine runs out of resources or extra resources are available it changes the method it is using to render the scene. Adapting to maximise the rendering speed is the main goal, while sacrificing as much texture memory to do this as possible. I have tried various methods of shadows, most require at least two passes, some fast hardware or advanced graphics features, shaders for example. Or pre bake, which locks all your geometry into one position. I'm looking for a halfway house, semi static and it needs to work on slow hardware, if possible. My game is 3D puzzler, set from a first person perspective. The puzzles are mainly logic ones but some are physics based. The basic level structures are predesigned with procedural methods used to alter the level design and certain puzzle elements. I really want a decent look to it and for it to make it onto the mobile Market without crawling. Last edited 2011 |
   |