OMG! Shadow system update!
Blitz3D Forums/Blitz3D Programming/OMG! Shadow system update!
| ||
| If you have my shadow system and you'd like a speed boost of up to 10%, send me an email and I'll send you version 1.24. In case you're wondering how I got this speed boost: I realised that if you have a frustum and a vertex is on the outside side of the left plane of the frustum, then it MUST be on the inside side of the right plane, and so on for the top, bottom, front, and back, because my volumes are cylindrical in shape, not conic like a camera view frustum. This allowed me to reduce the number of IF statements I have to do for each vertex when building my hash tables for my sutherland-hodgeman clipping by about half. But not exactly half, because I have no far plane in my shadow volumes, they extend to infinity. |
| ||
| ..I wan, I wan..I have pro version licensed.. :) |
| ||
| I don't see an email! I don't think you want it badly enough! :-) |
| ||
| sswift your shadow system works in terrain mesh? EDIT : I found the answer here http://www.blitzbasic.com/Community/posts.php?topic=76028 ... |
| ||
| What were you going when that idea sparked? I tend to find most of mine happen in the shower...... *looks on ebay for a waterproof laptop* |
| ||
| Someone asked if there was a way to make it faster and I just took another look at the code after a long time away from it, that's all. There's one main loop where it has to determine whether all the polygons in a receiver are inside or outside the shadow volumes, and that's the part of the code that takes the most processing time. It has to loop through all the vertices in the receiver first, and compare them to five planes and then loop through all the polygons and use the data gathered to decide if the polygons inside or outside. So for a 5000 polygon object it had to do 30,000 if statements or something like that. Now it does like 20-25,000. |
| ||
| I wonder what speedup you would get from using the render-to-texture DLL? Also, switching it over to C would give quite a boost. I would definitely buy it again if it had the above. :) |
| ||
| I sent you an email using this email devils[d.o.t]child[a.t]gmx[d.o.t]net please send it to me:) thank you! you are so gently by not taking money for an update! |
| ||
| ah nice one shawn. you can send the update to the email in my profile (as always...). now i have to think about how i can merge your changes with my render-to-texture code, compressed staticshadow textures, support for directional lights, modified blendmodes and the possibility to render single staticshadows... :O |
| ||
| Beaker: There's still plenty of ways I could speed the shadow system up, but I doubt there's many folks who'd fork over more money for it, so it simply isn't worthwhile for me to spend a couple more weeks optimizing it. OJay: The change I made is a simple one in the main update loop. I just replaced one For loop with a series of nested If statements. It's not likely to affect any code you've done. |
| ||
| I would pay for a faster one, if it work`s with B3DSDK and Pure Basic. :) |
| ||
| I don't even know what B3DSDK is supposed to do. And Pure Basic, forget it. :-) |
| ||
| thanks for sending me the update. i still have one question. this problem hasnt existed in the version 1.20, but it does in the version 1.24 if i have a cube and want it to receive shadows, i have to do UpdateNormals(cube) when i do, the cube doesnt look flatshaded anymore. but when i dont, the shadows are casted a meter above the cube. do you know what i mean? |
| ||
| Hey, this was my idea. I was asking about an update the other day. |
| ||
| Devil's: You need to adjust the shaodw offset global variable in the system to tell it how far off the surfaces you want the shadow to be. This value can't be determined automatically because everyone uses different scales for their games. |
| ||
| What about implenting a 5th, far plane? Surely no-one really needs shadows that extend to infinity? Plus, i'd pay for a faster shadow system too. Only two choices i have are your shadow system, or the ashadow one. |
| ||
| That would be a sixth plane, and that would actually slow things down in the general case as few people need shadows which cast high onto walls, and there's generally not going to be many polygons below the player's feet that won't be culled by the other planes. (The 5th plane is the one which passes through the middle of the caster so it doesn't cast shadows onto the ceilings behind it.) |
| ||
Global Shadow_Nudge# = 0.01this means that the shadows must be .01 meters far of the ground, but they are a lot higher above the ground. also i tell ya, when i use UpdateNormals on my receiver cube it WORKS, but the cube doesnt look flatshaded anymore! what now? ;/ |
| ||
| don't even know what B3DSDK is supposed to do. And Pure Basic, forget it. :-) Ok, i think it is easy to translate for Blitz3DSDK and PB. If i do this, can i use the translation in my own projects or do you not allow this? |
| ||
| Oh, I thought when you used updatenormals it messed it up. Your problem is then that the flat shaded cube's normals aren't normalized. http://blitzmax.com/codearcs/codearcs.php?code=975 This code won't do what you need, but you can modify it. Basically you need to loop through all surfaces, then through all vertices in each of those surfaces, and for each vertex do this: D# = Sqr(Nx#*Nx# + Ny#*Ny# + Nz#*Nz#) Nx# = Nx# / D# Ny# = Ny# / D# Nz# = Nz# / D# Where Nx,Ny,Nz is the vertex normal. Plug the result back into the vertex and you'll have a normalized normal (one with a length of 1) which points in the same direction it did originally. The only thing I don't understand is if it's not a change you made to shadow nudge, it must be something else you changed, because the ONLY change I made from 120 to 124 is to change a loop which checks to see which side of a plane a vertex is on. That code would have no effect on where vertcies are located or how the shadow mesh is built using the mesh normals. There's zero possibility of that. And one more thing: If you do normalize the normals of a cube like that, then you'll want to have the shadows very close to the surface, or else at the corners you'll see gaps. A normal at an angle pointing out from the corners of the surface will cause gaps like that to close up. But one pointing perpendicular to the surface will make side polygons the same size rather than a little bigger, so the gaps won't close. The only way to fix this would be to use an invisible cube with shadow friendly normals, one with shared vertices at the corners perferably, unlike the Blitz cubes, and make that the shadow reciever, and have the visible one not receive shadows. Oh and you could use that function I sent you as is to fix the cube. I forgot the Blitz cubes have seperate sides. The Blitz updatenormals function makes the cube smooth shaded because it looks for vertices near the same location and treats them as being the same one. Mine does not. I have no idea why Mark wrote his that way, I consider that wrong behavior. |
| ||
| Sigi: If you've licensed the system, you can port it to Java for all I care. :-) |
| ||
| I have licensed it in 2004, thank you :) |
| ||
| I have it too. |
| ||
| Puki, you can have the update when you EMAIL me. I'm not sending a free copy to Michael Abrash. :-) |
| ||
| thx shawn. merged your changes with mine successfully and it works flawlessly :) just a side note: it seems you made your new changes to an outdated version of your system (117 i guess), since my last version (120) already included the better code for static shadows. any reason for that? |
| ||
| I don't know what you're talking about. I modified version 120. I couldn't have modified an older version because all the old versions are tucked away in another directory. Send me the version 120 you had, and tell me what part of it is different. |
| ||
| Quote: Copyright 2003 This is a good thing, proof of continuity and consistency. Man, it's unbelievable how time goes by. Thanks for the Update! BTW who is Michael Abrash? |
| ||
| ok sswift. it works now. thanks :) |
| ||
| Michael Abrash is a famous programmer who used to write articles for Doctor Dobbs Journal, and has written books on optimization, particularly in the area of computer graphics. I don't know what he's done lately, but when 3D engines were all software based and people were still coding perspective texturemapping using affine approximation and hand coded assembly, he was maybe slightly less well known than Carmack. Oh, and that's the name Puki has listed in his profile with an AOL email address. |
| ||
| I estimate it would take about 2 hours to add (optional) render-to-texture DLL to it. Must be worth it to sell a few more licences. :) |
| ||
| Anyone who wants to render to a texture could easily modify the system themselves to do so. The DLL has a sample program, and the shadow system does all its texture rendering in one function which is fairly simple and seperate from everything else. If I implemented it myself I would have to document it and deal with people asking me where to get the DLL and how to install it. Also the DLL doesn't work on all systems that Blitz does, and I don't know how widespread the issues Bouncer complained about in the original thread are. It's just not worth it. If someone wants to implement it themselves and post the modified shadow system function here which makes use of it, you're welcome to do so, but I'm not supporting it. :-) |
| ||
| I have it now. I have version 124. |
| ||
| LIES! Michael Abrash has version 124. |
| ||
| I don't know what you're talking about. I modified version 120. I couldn't have modified an older version because all the old versions are tucked away in another directory. ok, i analyzed the differences a bit more and it turned out that all changes have to do with static shadows only. diving through my mail inbox i found an email from 2005 where you sent me a modified version 120. i complained about some glitches about static shadows and you adapted the static shadow rendering code to the dynamic shadow rendering code. now, to be precise, here are the line numbers (in 124) which are different to my version: 487-510: in my version the function Recursive_EntityRadius() is used instead of the two FOR loops 1740-1758 and 2507: all of this Shadow_Cam concerning code is commented out, since this camera is never used (since Render_Shadow() creates its own camera) 2696-2698 and 2766: the Glass_Brush is created only if the flag translucent is true in my version so, all in all nothing too complicated one would worry about too much...im sure both version are working and behaving the same... thx again for the update ;) |
| ||
| Hey swifty, or anyone else for that matter :o), implement render to texture and give us a speed difference. |
| ||
| [edit] You never saw this! [/edit] |
| ||
| Just did a render to texture test myself in another thread. Some interesting results in textures over 256x256. But anything at 256x256 and below, there is no speed gain. |
| ||
| What happens in textures over 256? |
| ||
| Well, i get speed gains of 50% for 512, and 70% ish for 1024. |
| ||
| Aren't you copying the rect from a 768 pixel tall screen though? So you can't copy a whole 1024x1024 texture then. So the 1024x1024 pixel copy with the render to texture should be even faster. |
| ||
| There's still plenty of ways I could speed the shadow system up, but I doubt there's many folks who'd fork over more money for it, so it simply isn't worthwhile for me to spend a couple more weeks optimizing it So piss on the many who already supported your shadow system by purchasing? doh.. |
| ||
| Hu? he offered 1.24, don't see how this could be called like that. Just because you don't want to spend money, don't assume that the author wants to spend time for 0.0 USD payment. Kids like you cause the main problem that nearly no professional developer invests the time to create great systems for Blitz3D ... there is just no market with that brickhead attitude. |
| ||
| Ah hush your mouth, I'm one of the original shadow system owners, I don't feel the need to have to explain myself to the likes of you. Your forum trolling ways is quite disturbing as you do nothing but lash out at people on almost every topic I read.... this topic wasn't directed to you. /ignore Dreamora If a product has 1 customer only and can be imporved, it should be. I'm also not lashing out at Swift, just saying if your not satisifed with the amount of customers your product has then perphaps these 'imporvmenets' would presuade more customers your way. Not an attitude of "'I'll release it as-is' and if i get paying support I'll make it better, maybe." |
| ||
| I own it since an eternity as well, but as a professional developer I understand as well that "working forever for free" on it makes little sense when the engine you wrote it for is on its last breaths (as BRL does not intend to make it future hardware compatible by porting it to DX9) so you have steady dropping chances to see new costumers. For the normal cases you sure are right: better product -> more mouth to mouth propaganda -> more costumers that said: Perhaps I didn't clarify that enough, but I surely would be happy about it as well as I own and use FastExt myself. I would surely consider a small donation wif it was fully and correctly implemented with potential optimations in mind. |
| ||
| I don't care what's happened between you guys but I think if sswift can speed up his library then he have to do it. Before a couple of days I was thinking to purchase the sswift's shadow and terrain systems but I am wondering why to spend some money while at the same time the author says that he can make his product better but he just don't want to do it... :( |
| ||
| I agree with Dreamora, on this rare occasion, a small upgrade fee would be feasable and one i would be willing fork out for any imporvments to one of blitz3d's only realtime animated shadow system solutions. |
| ||
| huh? Dreamora....do you not realise that Swampdonkey isn't a 'kid'? He IS one of the few developers who makes good blitz3D systems: http://www.gothasoft.com/ If anyone knows about commercial programming lib creating and support its him. |
| ||
| I will be buying sswifts shadow system soon, regardless of any updates he could do. |
| ||
| So piss on the many who already supported your shadow system by purchasing? doh.. I'm not pissing on anyone. You knew what you were getting when you purchased it, and that's precisely what I provided you with. I never promised that I would keep optimizing the code forever, day in and day out. There's a million ways I could optimize this system, and many of the others I have. The simple fact is, I can't AFFORD to spend time on something which isn't going to bring in any revenue. If I work on this all week, then I'm NOT working on something else which might actually bring in some real money. I won't be developing ANYTHING if I don't have a steady source of income here soon. I understand as well that "working forever for free" on it makes little sense when the engine you wrote it for is on its last breaths Yes, that too. I'm quite frankly surprised that as many people emailed me as they did asking for the update. I thought most Blitz users had given up on Blitz3D. but I am wondering why to spend some money while at the same time the author says that he can make his product better but he just don't want to do it. Whether I optimize the systems further or not doesn't change the state they are in right now. You should not purchase a product under the expectation that it will do what you want at some point in the future. You should buy it if it meets your needs right now. Also, keep in mind that most companies CHARGE for updates. Photoshop, 3D Studio Max... Anything used by commercial developers who expect there to be updates, those updates COST MONEY. I don't charge for updates. And yet here I am, making an update for a product which doesn't even sell one copy a month, years after release, FOR FREE, and you're complaining because I admitted that I don't have time to spend two weeks making a complete overhaul of the shadow system? The thing makes so little money I've considered GIVING IT AWAY FOR FREE. The only reason I haven't yet is because I still don't have some major product on the market which is bringing in a decent amount of revenue for me, so $20 every month or so is still welcome... but not nearly enough to justify major changes to a system which will become obsolete the second Mark releases BlitMax 3D. Also the reason I even mentioned that I could optimize the system is to let people know that it is possible for you to optimize it yourself if you really need that speed. Here, I'll even show you how: See how that function creates a receiver type, and stores all the polygon and vertex data in a bank? Well, if you don't want to bother spending the time to split your level up manually into small sections, then the next best thing would be to go into this function and modify it so that when you input one receiver into it, it creates several. All you have to do is split your object into a grid of whatever granularity you want, say, cubes 1 meter on a side, and then figure out which polygons should be assigned to each cube, with no polygon being assigned to more than one. Then make banks to hold those polygons and the vertices that go with them, and calculate the bounding spheres for them and voila, the shadow system will be much faster. You don't even need to know any 3D math to do it either. Just use the first vertex of the triangle to decide what cube it belongs in. And that's just if X > N and X < N2 etc. But this is something you can do just by splitting up your level in your 3D app. A lot of people don't bother to do that properly though, and then complain the system is too slow in their game. So it's not like the system isn't already optimized. This is just a "convenience" feature really. Saves you the effort of doing that work by hand, mainly. And yes, there's other ways you could split that up for even more speed, but a grid is by far the easiest to implement and doesn't require an overhaul of the whole system, and I doubt you'd get much more out of using octrees since you're not gonna subdivide each receiver that much. I suppose if you were absolutely insane and had a million polygon terrain with grass on it and you wanted to cast shadows onto the grass, then maybe you might want octrees, but I'm not even sure Blitz could handle that. |
| ||
| for lazy people, rottbott somewhen uploaded the chunked mesh source that creates a grid of submeshes from one main mesh. this would allow you to pass a usefull entity into it (thought I prefer my room based portal - pvs system as it allows me to switch of particles, animations, collisions and shadows the moment they are not needed anymore) thank you for pointing that out sswift. huh? Dreamora....do you not realise that Swampdonkey isn't a 'kid'? I know that he wrote the GrassParty / TreeParty libraries. I compared his behavior to the "common behavior" of given age groups. Given the fact that he behaves there exactly like I mention above on his own libraries its interesting that he assumes that someone else for a similar priced libary, behaves far different from him and spends countless hours on implementing something without generating further income. This does not mean his libraries are not great, they are still on my to buy list so they definitely are :) (and that thought I own BlitzGrass and BlitzTree3D!) But so is Sswifts shadow system, its very performant and powerfull if used correctly and he has definitely brought it to a great level in the past since I originally bought it. And it is already far more capable than originally advertised :) If you ever intend to push it to a totally new level with a V2, let me know, I'm sure I'll buy a new license / upgrade license :) |
| ||
| A bit more info on that optimization: Right now, the system culls each reciever based on a bounding sphere. But the polygons inside that receiver it has to interate through. But, if you split a receiver with 5000 polygons into 50 smaller recievers each with 100 polygons, then the system will be able to cull most of those receivers with one check instead of the 100 those polygons would normally require, so it will be doing 100x less work. And you can do that in the function above, because the polygons get stored in banks, and that's what the system accesses. It needs the mesh pointer only so you can move the receiver around, and it won't matter if 100 receivers point to the same mesh for that. The only thing is, I don't actually know how much this would speed up the system in the general case. Everyone's game is different. If your game is slow because every shadow falls across 20 polygons at once, then this optimization won't speed it up. Building meshes in Blitz is slow. If it's slow because your animated characters have 10,000 polygons each and it needs to copy them to render the shadow, this optimization won't help. If it's slow because you want really high res shadows or blurry shadows, this won't help. But if it's slow because you haven't split your level up and you're casting shadows onto it and it's got 5000 polygons, then this would speed it up. But so would splitting that level up into smaller bits. |
| ||
| And it is already far more capable than originally advertised :) Damn right. When I started selling it, the only thing it could do was cast fake texture shadows straight down. So it's not like I've barely upgraded it. |
| ||
| sswift: You have your point of view and I am respecting it. But: When I don't want to spend my time to reinvent the wheel then I spend my money and I want a ready to use solution. Think this: You are going to buy a new car and the seller says: "Here is our new model. It fits you needs right know! It could be better but the designers believe its not worth to spent more time because you are the only you are going to by it. So this is YOUR car!" |
| ||
| Moraldi: Uh, every car you buy is like that. You think they couldn't make them out of titanium and super light so that they use very little gas? They could. But they don't because it wouldn't be profitable. They're just not honest enough to admit they do that. |
| ||
| yea Moraldi, thats pretty much the process with anything thats build, and using your car theroy, why do you think there are cheap cars, and really expensive cars? |
| ||
| sswift: Does your shadow system support self-shadowing? |
| ||
| Did you get my email? |
| ||
| @JA2 ..so far I was unable to engage self shadowing with Swifty system, but he may reveal some tricks to get it work :) |
| ||
| Pongo: Yes, but you apparently didn't get mine. I guess BCC doesn't work with Yahoo. JA2: No. Self shadowing a level requires stencil shadows, or precalculated lightmaps. Doing it by rendering shadow maps in realtime is completely infeasible. You'd have to render one shadow map for every polygon essentially. And if you're going to do that, you might as well just project the polygon onto the surrounding surfaces, and draw it perfectly sharp like a stencil shadow. But even just doing that and skipping the texture rendering phase would be horribly horribly slow. The only way you might get some sort of self shadowing in realtime that doesn't use stencil shadows is to cast rays from your light source and color the vertices depending on whether they are occluded or not. But that wouldn't be very pretty, and it also would be too slow, because it requires reuploading the mesh every frame to the card. (You might get 15fps if you're lucky.) And forget about self shadowing an animated mesh without stencil shadows. That's beyond impossible, since you can't get the changing vertex locations. The reason my shadow system is as fast as it is is because it can acess the mesh data in ram, and it only uploads small new meshes with a few polygons to the card each frame. |
   |