YAL code - flat shaded?
Blitz3D Forums/Blitz3D Programming/YAL code - flat shaded?
| ||
| Hi all, I've been playing around with YAL from the code archives, and I've noticed what seems to be quite a big problem with it. It works perfectly to lightmap cubes, rooms, or other objects with sharp edges, but if I try to lightmap a sphere, terrain, barrel, or anything like that, the result looks a bit like it's flat shaded. Is this a "feature" of all lightmappers, or is there a way to make YAL lightmap curved surfaces properly that I'm missing? :-) If it's important I'm using sswift's version.. it was nearest the top. Link - http://www.blitzbasic.com/codearcs/codearcs.php?code=794 |
| ||
| As far as I know this is a "feature" of all lightmappers - unless they utilize some crazy magic. I think it's the way it works. A LightMapper would have to check for DX lights to realize how the smoothing should be added to the lightmap. I think if at all, there are only a very few Lightmappers which do support smoothed surfaces. How about gile[s]? I don't know, just a question. |
| ||
| gile[s] preserves smoothing :) But you can set it to use flat shading if you like. It's not crazy magic, but it's not that easy to do either :) |
| ||
| >>not that easy<< bah - you do use magic, confess! (someone call an inqisitor - you know, a holy one) :P Seriously - hats off. |
| ||
| This certainly is not true of all lightmappers. gile[s] handles smoothing fine, as does lightmap calculation in tons of level editing tools (Worldcraft, etc.) plus baking lighting into textures in tools like 3D Studio Max and Maya is smoothed correctly. Thing is YAL unwelds everything before lightmapping. |
| ||
| Fredborg, I can't use Gile[s] for this, I have to do it in code. :P If I stop YAL breaking up the triangles, how can I make it handle each smoothing group in the same way as it currently handles each triangle? Is that even what I want to do to achieve smooth shading? Or do I have to somehow write my own lightmapper? Perhaps Mr BlitzSupport has a useful link? (He has one for just about everything else..) Argh, I'm getting a headache just thinking about it! |
| ||
| I've been doing some reading, and I *think* the problem is this: YAL just takes a normal for the whole triangle, instead of interpolating the light levels based on the vertex normals of the triangle. So: A) Fredborg, can you tell me if I'm even along the right lines here? You've written one, you ought to know :) B) Am I right in thinking that it would actually be fairly simple to make YAL interpolate the normals to adjust the colour of the lightmap texels, rather than write a whole new lightmapper? |
| ||
| OK, I've narrowed it down to this: I simply need a way (in YAL), to get the vertex indices of the triangle which the current lumel is on, when adding light to a lumel. Anyone got any ideas? (Sswift? You've worked on YAL). |
| ||
| Just pull the finger and wallet out and pay for your betters: gile[s]... |
| ||
| As he said, he needs it in code, so gile[s]'s not the solution here. Rottbott. You need to be able to read the smooting information, or, you could also use an average smoothing on angles less than say 45° then simply throw some sinus factors onto the lumel brihtness and there you go. the only problem seems to be to involve NX,NY and NZ to determine the angle of two tris (or maybe you need to do it quad-wise?) |
| ||
YAL - Yet Another LightMapper (update 1.5 ) BTW, I haven't cleaned the code before posting. :) |
| ||
| Brilliant, thanks very much Marcelo! Now to try and figure out how the heck you did that >:-] |
| ||
| Looks good, but isn't the sphere still flatshaded? Or at least showing seems? |
| ||
| Peter: Looks smooth to me... but there's jpeg blocky artifacts all over the image. [edit] No.. you're right.. I ran the demo... the sphere is not smoothed properly. I think it's better than it used to be but still has quite obvious seams. [/edit] |
| ||
| Anyway, a step forward. thanks a lot! |
| ||
| Out of curiosity, if I were to make a system (for sale) which would render lightmaps a hundred times faster than YAL, would that interest anyone? I think I know how to do it, but unless there's interest it's not worth my time cause I have no need of a lightmapper myself. |
| ||
| how big should that interest be, in $? and would this include smoothing groups? |
| ||
| Oh I'd sell it for the same thing I sell everything else for probably. And yes, it would support smoothing through vertex normals. |
| ||
| Swift, I would probably buy it. |
| ||
| speed isn't such an issue to me since i can easily render a huge lightmap over night if I once know how to use a tool "blindly". What matters is the quality. If you beat gile[s] in features I would think about it - tho I hate to buy tools twice. |
| ||
| Gile[s]? Ahahaha. :-) Fraid not. If I wrote something of the level of Giles I'd have to charge a lot more for it than I do for my systems, that would take months to write! Anyhow it was jsut a thought. I'm probably not going to attempt it. |
| ||
| I mean, it's always a good thing to make something faster. How about to do somethng together with Fredborg? You can send him a simple demo, he may buy the idea or let you participate. |
| ||
| I had a play with Marcelo's latest version and still puzzling over the smoothing algorithm. Once I confirm that the triangle area ratio is fine and that better spherical shading is not possible without a special case (as in you can not use linear interpolation without suffering seams) I'll post some of the optimizations I made while testing. |
| ||
| a good quality real time light mapper based on lights placed in the blitz scene, if you could do that swift then i would buy it. maybe even intigrated with your shadow system and made as an overall lighting package |
| ||
| For smoothed objects, maybe a simple per-vertex LightMesh() is the better option. :) This is a quite old code, the planer mapping is not suitable for smoothed objects, there are much better unwrapping algorithms for this. FredBorg, what about a gile[s] SDK, possible? :) |
| ||
| One thing about YAL if you have an odd triangle that won't make a full quad it ends up with odd shading on corners |
| ||
| really? I never realized this. |
| ||
| I can't use giles. The way my levels are built prohibits that without writing a bunch of code to convert the levels back and forth. My light maps aren't as important ot the game as other things. YAL does the job great but it would be nice to have a Giles SDK similar to YAL. You could sell a version for personal tool building and a more expensive version for redistribution. |
| ||
| The problem with YAL is that it combines lightmaps into "surfaces" which are polygons that are adjacent and have similar normals. If it just mapped each tri seperately, then it would be trivial to get the smoothing right. The problem is not knowing which triangle the particular lumel you're mapping is in. Now, one could write a slow algorithm to figure this out after the fact, but it would really be much simpler and faster to toss out the special case stuff. There is no need to compress lightmaps so much in today's games. |
| ||
| Sswift, if you do this lightmapper, I'll buy it. |
| ||
| I'd certainly buy the lightmapper, Sswift. I'm working on a world editor at the moment, which I'd like to add a lightmapper to. I'd happily pay the commercial license price (or more) for it, too, as it would save me a heap of work. |
   |