Phosphore Radiosity demos
Community Forums/Showcase/Phosphore Radiosity demos
| ||
| Hi. Here are 2 demos that show the difference between simple lightmapping and Radiosity lightmapping done with the forthcoming "Phosphore 1.0" editor. Press [F1] to switch between modes [lmp/rad] . http://telias.free.fr/temp/examples.zip   Bye. |
| ||
| Looks awesome... When is Phosphore going to come out? How much will it cost? When can we expect a demo? Right now I use Cartography Shop for modeling (and I really like it for modeling)... but the lightmapping leaves much to be desired. A good lightmapping tool would come in really handy! |
| ||
| ohhhhhhhhhh drooling.... |
| ||
| It looks very nice. I hope you're going to try to fix the issue with the bleeding around the edges of surfaces, like at the bottom of the pillars in the above examples. Hm... But now that I take a second look at it, it looks like both versions have the same lightmapping issue. And if I am not mistake, that second level is a maplet level? So maybe pert or all of the issue is with how maplet sets up it's lightmapping coordinates. But I dunno about that, cause there's no way to make lightmap coordinates line up perfectly with all the texels. So all games must have to make corrections for this issue during the lighting calculations themselves. I wonder if one could solve this by calcualting a lightmap with 2-4x the detail level, and them averaging it down. That then would make it so that if a texel is mostly outside of an object, 4x as many pixels might be lit as unlit, and the averaging of them down to a single pixel color would result in a drastically reduced darkening effect on those pixels where the center of the texel is inside an object. But I'm not sure that would entirely solve the issue. Maybe just reduce it by half. I think what you might need to do is sample the 4 corners of each texel, and if any of those is exposed to the light, then the pixel is calculated as if it is in light. Or you might be able to calcualte the lightmap at 2x it's width/height, size, and then take the maximum pixel color in each 4 pixel square when downsampling to a single pixel, instead of averaging them. |
| ||
| Hi. @Rex. A demo should be in one month out. And it is not just a lightmapping tool you can create a map from scratch with it. The reason I have not yet anounced a full list of features is because that some things might or might not make it to the final release. @sswift. I don't know exactly what you mean here because the bleeding is near to zero in both levels. Perhaps you see a DX thing where looking form a certain distance a level causes a pseudo-bleeding. The compiler has a built-in autocorrection-bleeding eliminating system. The only texel size that is a little problematic till now is the 2x2 texel size. Thanks for your suggestions but it is more of a 2nd uv coords shrinking matter. So by shrinking a little bit more the 2nd uv coords it is likely that this will not show up. And there is no interference with maplet. The second maplet-level was just imported and compiled in Phosphore. Bye. |
| ||
| Good stuff. I have a couple of questions: 1: What kind of light types do you have? 2: How long does it take to render the second example WITHOUT radiosity? 3: How long does it take to render the second example WITH radiosity? 4: Can you adjust the radiosity iterations? Fredborg |
| ||
| "I don't know exactly what you mean here because the bleeding is near to zero in both levels." It's not anywhere near zero. It's quite obvious. "Perhaps you see a DX thing where looking form a certain distance a level causes a pseudo-bleeding." I don't think mipmapping could cause this level of bleeding, and even if it is mipmapping, it can be corrected for, because almost every game does. I think Unreal is the only engine which actually uses the effect to give the game a unique visual style, though the option is in the editor to correct the issue. Take a look at this image. Every dark edge that I have jighlighted shouldn't be there. It's caused by the lightmapper thinking that that particular texel is in shadow, because the center of it is inside the wall:  As you can see it's not at all near zero, it's all over the place. I didn't even circle half of them. You can see this on the second shot too:  That black line along the wall in the hallway shouldn't be there. "The only texel size that is a little problematic till now is the 2x2 texel size." I don't understand what you mean by this. "Thanks for your suggestions but it is more of a 2nd uv coords shrinking matter. So by shrinking a little bit more the 2nd uv coords it is likely that this will not show up." I don't know how you expect to "shrink" the UV coordinates, though I suppose you might be able to use a 2D version of the algorithm similar to the one that is used to expand a mesh for cel-shading. But I suspect you're not actually talking about something like that. Anyhow, don't get me wrong... I think a radiosity tool like this will be immensely useful. It's quite clear that radiosity makes the models look a lot more 3D, and the lighting a lot more realistic, and it's not something which is particularly easy to program either. I just think this is something that needs to be corrected. Or, consider making it an option to correct this. There may be those which like the Unreal-like look to the lightmapping. It can often make a room with really boring lighting actually look better. But it does give it more of a cartoon style look. |
| ||
| I agree with sswift, I have noticed similar edge problems in lightmaps generated in [removed cos it's not true] and any product that uses the YAL lightmapper. It really ruins the effect of lightmapping... I'm trying other commercial tools at the moment to see how accurate they are. btw check out this tool, I've not had much chance to experiment yet, but it might be of interest -> http://www.windssoft.com/ |
| ||
| Looking good elias you can really see the difference with the radiosity lightmap. |
| ||
| Hi again. @Fredborg: There are 2 categories of lights: 1. Normal lightmap lights: omni,spot,sun 2. Radiosity emitter lights: cube,cone,sphere,cylinder or Any mesh. You can scale and rotate these emitters and even attach a texture to them so the texture will act as a light emitter. On a Celeron 561 Mhz The second example takes 3 minutes to compile and the same with radiosity 7 minutes. As for the iterations. I actually don't call them iterrations but I call them "passes". There are 1 or 2 passes you can run for radiosity. Because of the method used to produce radiosity these 1 or 2 passes are enough to produce very good results. Here is the compiler options screen:  ;--------------------------------------------------------------- @sswift. I don't get you wrong. But now I understand what you mean. Ok this Not a bleeding problem actually. The thing that you point out depends purely on what resolution you lightmap the level. You cannot expect from a 12x20 texel size to represent with high quality the shadow/light resolution. If you raise the resolution these lines tend to dissapear. ;-------------------------------------------------------------- @Caff. Yes I know that program. And here also this phenomenon is also lightmap-resolution dependant. here a snapshot of this program:  ;------------------ Bye. |
| ||
| For the record, Cartography Shop no longers bleeds like that. |
| ||
| Quill3D doesn't bleed at any lm res either |
| ||
| looks great!!! how much will it cost |
| ||
| " For the record, Cartography Shop no longers bleeds like that." So, how did you solve the issue? |
| ||
| Thinking about this a bit, I reckon I know why this bleed occurs - it's because the lightmap is blurred to achieved smooth angular shadows, but this also affects joins in the lightmaps that don't touch the edge of the lightmap image... hence it's a problem with the lightmapper. I would imagine to stop this happening you would only blur locally to a face within the lightmap image. (only a guess though) |
| ||
| For the record, Cartography Shop no longers bleeds like that. No... but Cartography Shop doesn't let me render when I am in 1280x960 screen mode. I have to lower my screen resolution to 800x600 to render... And Cartography shop will not properly render a lightmap higher that the graphics card can produce (so if your graphics card can only support 512x512 sized textures, for example, and you try rendering 1024x1024, it will not map properly). |
| ||
| That emitter stuff looks good... If you can get lightmapping right, the results are great. I look forward to seeing this project take shape :-) |
| ||
| "No... but Cartography Shop doesn't let me render when I am in 1280x960 screen mode." Oooh... that's sucky. It means that Halo, for whatever reason is generating the lightmaps using the video buffers, much like I generate shadow maps using the video buffer. But it doesn't seem logical to do that for a lightmap. The way lightmaps are generated... It just doesn't seem like that would be any kind of optimization. Hm. I could see him doing that for generating the individual lightmaps, but those would each be much smaller than the full lightmap size. So that couldn't be why he's doing it. Maybe he's generating the smaller lightmaps and then adding them to the bigger one using add blend sprites instead of manually calculating how to add the colors together. It may be for speed, or maybe he just decided to do it that way cause it was easiest. .... "And for the decor(d) I am Ghengis Chan. I still insist on what I am saying. sswift Is correct, only (I think) he is using the word "bleeding" in a wrong way." That's an amusing claim from someone who claims to be "Ghengis Chan", for the "decord". :-) I think you meant Ghengis Kahn, and for the "record". :-) "UNLESS there is a supa-dupa-funky top secret formula that I am not aware of, that splits a single pixel in more subpixels [yeah baby]." There is a secret formula. And that is to make those pixels which are partially in shadow and partially in light to be completely in light. There's a number of ways to do this. Also, you can reduce the effect greatly if you just make sure that the center of the lightmap pixels is aligned to the grid in such a way that the center does not fall on edges of the world geometry which is aligned to the grid. This won't solve the diagonal cases, but it will get rid of most of of the effect. But you should still work to fix the diagonal case too. "Oh look... no "bleeding"" Oh? I see bleeding. IF you look at the lower edge of the cube, it doesn't look sharp, it looks fuzzy. That's cause even though the lightmap is higher res the edge still has a black line there. So long as this is not fixed, no matter how high you make the lightmap resolution, there will always be a black line there. You'll just make it smaller and sharper the higher you crank up the lightmap res. "Oh... maybe is it that the pixels are not enough to represent it right?" It is only partially correct to state that there aren't enough pixels to represent it right. That is true, however because the offset of the pixels is off by 0.5 of a pixel, you're getting the worst case scenario. But even if you fix that, you can't ever perfectly line up the edges of a triangle with a texture that has square pixels. One line will always have to be diagonal and cross partial pixels. So you will always have this problem unless you correct for it by detecting pixels which are partially in light and placing them fully in light instead of fully in shadow. Well I'm done trying to convince you. :-) I know what I'm talking about. :-) If you don't want to beleive it, there's nothing more I can say that will convince you of the truth. You'll figure it out on your own someday. :-) |
| ||
| Hi. @sswift. I never felt that you are trying to convince me. And also I don't feel that there is a truth out there hiding from me :) But here are some facts : 1. this phenomenon is caused also by the blurring of the lmp image. [wich is a must for lightmaps] (I have already tried an alternative solution applying antialiasing and not blurring but with not much difference) 2. the lmp res makes a huge difference. 3. the determination of pixels partialy in shadow or in lights you mention: I have already tried this with good results on one front but on the other it makes the shadows look harder. I surely will give it more tries to minimize it but I still suspect lmp res takes the first role in it. thx for the constructive comments. ;------------------ And for the record:   Bye. |
| ||
| "the determination of pixels partialy in shadow or in lights you mention: I have already tried this with good results on one front but on the other it makes the shadows look harder." Okay well that may be true. But I suspect that that is because of the way you implemented it, so that it does not just activate when the texel is actually adjacent to a surface. "And for the record:" I'm not sure what these screenshots are supposed to show. Is that CShop? Or something else? |
| ||
| Those screens are from Quill. The lightmaps in quill definately bleed. From the screenshots I have seen Cartography shop has the bleeding under control the best but it still isn't perfect. |
| ||
| Not sure if this helps... two cubes one as the floor, both textured the same, both light similarly, lit in two separate packages: Max 5.1 render:  CShop 3.02 light map:  Interestingly CShop (like Max) has the ability to render with no shadows cast). I will try and get the lighting in CShop a little more like the Max one if I can...I'll post it later and remove this comment if I suceed. IPete2. |
| ||
| The latest version of Quill3D does *not* bleed. I know - I use it all the time. Those screenshots must be from the earlier versions - which did bleed. |
| ||
| http://www.blitzbasic.com/gallery/view_pic.php?id=100&gallery=&page=1 You telling me there is no bleeding in this shot? I can see loads... unless there has been a new patch that I'm not aware of since you made this? Anyone trying to spot the dodginess. Look in the tunnel at the joints between the polygons. I'm pretty sure those black seams are unintentional... of course if could be part o te design. |
| ||
check this newer shot: and  I didn't make Quill3D btw - it is Birdie's creation. I'm merely a tester and avid user. I do have a more up to date version though, which should be released at some point in the near future. |
| ||
| Where can I find Quill? I'l like to take a look at it. |
| ||
| sswift - http://www.quill3d.tk |
| ||
| Hey people Thanks for converting this thread to a bleeding competition. [but what do I know?] |
| ||
| I find Quill3D lightmaps go weird at the edges of brushes i.e. where vertices/edges of different brushes meet. Extreme example rendered on the highest lightmap setting  In CShop this shadow would be rendered with no artifacts,lightmapping is one of the things CShop does really well...just a shame about the random crashing =/ |
| ||
| well i liked it elias :) |
| ||
| Ravey - that deep-thought looking model (or power station) in your first screenshot looks amazing, really great design! -E |
| ||
| @Ravey Which version do you have? Im using Version 1.2 which does things like this...  The left hand wall/ceiling edge clearly shows a lightmapping error. Nice pics btw =) |
| ||
| Elias - fair comment - my apologies, ill answer shambler and get off your thread. Shambler - thats prolly due to the walls overlapping, let the walls just meet and you wont get that problem. i have version 1.21 |
| ||
| I still see lightmap bleeding in ravey's newer shots on the floor of the tunnel and the right wall near the floor. |
| ||
| sswift - its not bleeding, its caused by geometry overlapping - in my piccies thats my fault - my screenshots are only from a slung together concept shot so i was a little slack placing things. |
| ||
| Until someone comes up with a better term than "lightmap bleeding" to describe this, that's the term I'm going to use, because that's the term I've always used and heard used. And I understand how overlapping geometry is part of the issue. However, that is not the only time it can occur. Any angled surface will have partial texels, some with the center in the wall. This issue can be solved, and should be solved. So if you're saying there's no bleeding, and that it only looks that way because you placed the geometry poorly, then you're avoiding the issue. This is correctable. So if Quill doesn't handle overlapping goemetry right, then that means it hasn't solved the underlying issue and thus it still has bleeding. If you have to construct your levels in a Quake style then you can't expect people to never have overlapping things in the level. |
| ||
| It is indeed a problem if you want to construct rooms by hollowing out a box shape. Since this generates overlapping geometry you are going to get lightmapping irregularities. The whole idea behind creating rooms like this is that it is fast/easy to do, if you have to then adjust the walls of the room you created you might as well build it as separate walls in the first place. Maybe when hollowing out a shape there should be an option to not create overlapping geometry. |
| ||
| ... this whole discussion has been verrry interesting and a bit informative for me. apologies to elias... who, by the way, has fine tuned his lightmapping work (i remember a while ago you had some lightmapper code up) to a new sharper edge... ... the demos looked great. --Mike |
| ||
| Maybe when hollowing out a shape there should be an option to not create overlapping geometry. Quill3d doesn't export untextured faces therefore if you create a room from a hollowed cube and just texture the interior then you don't get overlapping geometry. I think most of this discussion is nitpicking - so what if the lightmapping is not 100% accurate in any of the above mentioned apps - nothing else in a 3d game is 100% accurate - indeed far from it - if it were we would have photo-realistic levels ! I can't recall my enjoyment being ruined while playing any 3d game because the lightmapping wasn't 100% accurate ! |
| ||
| The mesh and texture radiosity emitters looks very cool! |
| ||
| Can't wait to see Phosphor! Radiosity rules. And that bleeding - think of it as if it was dust - a feature! :) Congratulations Elias! |
| ||
| A top achievement ! Radiosity lightmapping means realistic lighting. Incredible job! |
| ||
| Quill3d doesn't export untextured faces therefore if you create a room from a hollowed cube and just texture the interior then you don't get overlapping geometry. The interior faces of a hollowed out box do overlap and so even if you just texture those faces you will get the lightmapping 'nit pick'. =) Anyway, to avoid this problem I now just make a room from separate blocks which don't overlap, once you have made one its trivial to copy and resize it to make another. True, there are lightmapping errors in many games out there, some much worse than what we have seen in the pictures contained in this thread. I can't wait to nit pick about HalfLife2/Doom3 lightmapping errors ;) |
| ||
| Looking good elias, don't give up. |
| ||
| Ey guys, do not steal Elias post! You can make a new post to discuss Quill bleeding or whatever you want! |
| ||
| Nice one Elias. |
| ||
| How long now 'till its released Elias? Not trying to rush you - just keen to try it out :) |
| ||
| Because I heard it asked, CShop draws lightmaps to image buffers and then adds them together. |
| ||
| Bleeding issues aside, I'd like to hear more about the program itself. Create maps from scratch? Sounds really nice! Any shots of the interface? Is that Roman building in the picture something made with this program? |
| ||
| Here's how you avoid it: I am guessing a lot of the bleeding comes from rays that pass by the edges of a face and "miss" hitting it. CS2 had this problem. When lightmapping a face, don't consider it a triangle, just consider it an infinite plane. You should be tracing rays onto this infinite plane, over an area a little wider than the face you are lighting. Anything in front of the plane will cast a shadow, and anything behind the plane we don't care about, since that wouldn't affect the triangle. |
| ||
| to Tranz: I don't know if is ok I answer in place of Elias, but as I'm a betatester of the software, I can say that: - Yes can build map from scratch with the more sophisticate techniques (like import b3d/3ds/x mesh, a bunch of prefabs, blitz primitives, and boolean ops), and of course will manage also "entities" and not only geometries. - Phosphore will be (as far as I know) able to import almost any kind of 3D format complex hierarcic meshes, done with the modeler you like, then place your entities, press save map, then compile, and have your level straight ready for the game. I hope all this informations will be correct, only Elias can really confirm them all. |
| ||
| Sorry for dragging up this old post, 38 mins after Christmas day (UK), but does anybody know if elias_t ever relaesed Phosphore ? Merry christmas everyone. |
| ||
| As far as I know: no. It seems when he studied medicine he had less time for blitz programming. |
   |