I'll write a tutorial for dynamic lights and decals if Blitz3D gets more than two texture coord sets.
Blitz3D Forums/Blitz3D Programming/I'll write a tutorial for dynamic lights and decals if Blitz3D gets more than two texture coord sets.
| ||
| I wrote routines for dynamic lights and decals on walls, using the same method as Half-Life, but have no way to display them with the texture and lightmap. If Blitz3D had 3 sets of texture coords, I could display dynamic lights for gunfire or moving lights. If Blitz3D had four or more sets of texture coords I could display decals for bullet marks and blood splatters that actually wrap around the walls, and don't go over the edges. I asked Mark for additional texture coord sets, and if he adds them, I'll write a tutorial to show how to easily implement these features. The other way to do this, of course, is by changing the Blitz3D depth function. In OpenGL, a value of GL_LEQUAL will blend together two surfaces that are exactly on top of each other. |
| ||
| Cool. your some guy Halo ;) How many uv co-ords sets do direct x support? |
| ||
| In order to only need 2 sets of UV coords, couldn't you.. Keeping a copy of the lightmap texture write your dynamic lights into its pixels, in effect overwriting the static lightmap information where your dynamic lights are. Then draw the current frame using this new texture which has the static and dynamic lighting in it. Then copyrect the original lightmap to overwrite the dynamic lights. Thinking further, you only need to keep track of which areas of the lightmap you dirtied with the dynamic lights and copyrect from the original lightmap to reset these pixels only when that dynamic light changes. This of course assumes that every triangle has it's own individual area of lightmap texture, so no optimisations would be allowed in the lightmap texture for triangles with the same lightmap shading to share the same pixels of the lightmap...not sure if you do this with cartshop anyway. Hope my long winded explanation is understandable -.- |
| ||
| I'm not sure why it always has to be wrapped up into some kind of deal. I think there's a legitimate purpose for more than 2 UV sets, and that - as a feature request - this is perfectly valid. So on that basis, thumbs up, agree, yes please, can we have this? |
| ||
| Well, I assume theres not much point writing a tutorial without the extra set of uv's ;) |
| ||
| Yeah, but this "If I get what I want, I'll.." thing seems bound to annoy those who use every thread Halo starts as an opportunity to engage in a little bashing. I just think if it's a legitimate request for something that's genuinely useful ( and in my opinion it is ) it would get more credence and be taken more serious if it came without the baggages.. just a flat "This would be really useful." |
| ||
| Yes, and most likely very easy to implement for mark(not sure of it though). Sounds like a good idea to me. |
| ||
| Drawing pixels to a lightmap is too slow for dynamic lights, and too low-res for blood splatters. Blitz3D has the capacity to do dynamic lighting, and I just one little feature request from Mark, and I'll show you how. It's pretty easy, you just make a calculation based on the normal of the face, the distance of the light, and the light's position relative to the face. Hard to describe, but the math is simple. I'll post the code if anyone wants, but you can't really do much with it right now. |
| ||
| I've wanted this for ages too. It would also allow you to do some excellent stuff with terrains (or custom terrain meshes) eg. small repeating grass texture on layer 0, dirt patches on layer 1, rock patches on layer 3, lightmap on layer 4 - that sort of thing. |
| ||
| Once you have an object mapped with planar or cubic texture coordinates you can use PositionTexture, ScaleTexture and RotateTexture to postion different texture layers on a surface. Not that I disagree with the request... |
| ||
| I considered that, but then each face requires a separate copy of the texture, right? |
| ||
| It's a good request for many many other reasons. |
| ||
| How about this...a sort of modified "draw dynamic lights to the lightmap" approch... Load the lightmap as a image kept in system memory (call it lightorg)...create a seperate system memory image of the same pixel size (call it lightscratch)...then create a texture that same pixel size as the lightmap (called lightmap) Then for each dynamic light create a pivot at it's location with the same radius and use the entity visable function to deturmine if the effects of this light will show onscreen... If so you can do all your lightmap modifications to the lightscratch image...setbuffer to the lightmap texture and draw the lightscratch image there...this should work faster then the writepixel fast method as it optimizes the system to video transfer bandwidth...writepixel is fast...but everytime you call it the video card not only needs the color, but also the location within the surface to place the color...so in effect you are sending twice the amount of data to the video card... |
| ||
| Wouldn't it just be better, faster, easier, and more efficient if this feature were just added to blitz? Not a difficult change to code, and the advantages are endless. I think that this would be an EXCELLENT addition to b3d. -Matt |
| ||
| Not to sound odd, but halo's right in this case, the only other way to do proper dynamic lighting in blitz right now is multipass rendering (2 renderworlds) I've done dynamic lighting in blitz as well and i'd personaly love some extra layers. :) Scratching to lightmaps isn't fast enough, what you do to achieve proper dynamic lights is adjust the UV sets and texture them with a light/decal texture. |
| ||
| agreed it would be nice to have extra channels :) |
| ||
| You don't need another set of UV coordinates to create dynamic lights. First of all, unless you're writing for ulta high end cards (higher than Geforce 2 say) you can't assume the user even has more than two texture channels. And if the user doesn't have four texture channels you're gonna end up using one additional surface for every texture unit you attempt to make use of past number 2. So four simulated texture units will actually create three surfaces, and waste one texture unit on each of those two extra surfaces that you could have used for better effects. "I considered that, but then each face requires a separate copy of the texture, right?" No, each dynamic light requires a seperate texture and surface. To do dynamic lights, you need one adidtional surface for each object that will be dynamically lit. This surface has two sets of texture coordinates. The first set you set the U to the X coordinate of the vertex, and the V to the Y coordinate of the vertex, and the second set you set the U to the Z cooridnate of the vertex, and the V to 0. You leave both set to multiply mode, but set the blend mode of the surface to whatever you need to for your particular game to blend it with your lightmaps or texture. IF you're just blending with a texture then multiply. Lightmap, you probably want add. Then you simply apply the texture and offset and scale it as neccessary. The textures need to be loaded with UV clamping on, and the XY texture needs to be a circle of light that fades to black at the edge of the texture. The Z texture needs to be a linear gradient going left to right from black to white to black. Obviously this is not the least expensive way to do dynamic lights. A method which takes advantage of hardware vertex lighting would probably be a lot faster since you could do it with just a single surface. You'll have to subdivide large walls though if you want them to look good with a vertex light in the center though. But even if you subdivide each wall into 32 polygons, that's gonna be a lot less expensive than having even 2 dynamic lights with the texture method. You can probably have 4-8 vertex lights lights and still have it be less expensive than just 2 texture lights. |
| ||
| The idea of having more layers is making it less heavy to run and make use of the latest hardware which doesn't mind dealing with dense multitexturing. It's far from something we absolutely need though, since we can already pull it off by multipass rendering or as sswift says, getting an extra surface instead. There's plenty of smaller things that could have a greater impact on blitz's abilities. |
| ||
| How can you do multipass/multisurface rendering without either major z-fighting or seeing through walls? |
| ||
| Blitz renders surfaces in the order they are created in the object. So, surface 1 you leave normal, but surface 2 and later you set the vertex alpha flag for the surface. The vertex alpha flag will cause the renderer to test the zbuffer but not write to it. As both surfaces are at the same exact location in space, and always rendered in the same order, there is no z-fighting*. And you can't see through any walls because you render a layer which writes to the zbuffer first. (*Or at least, I never saw any when I helped someone implement vertex alpha blending in a terrain engine.) As for multipass rendering, you can do the same thing. Render the first pass with all surfaces set to have zbuffering, but render the second pass with all surfaces set to have vertex alpha enabled. |
| ||
| That's interesting. I think another texture coord set would be much simpler, though. |
   |