b34r

Members
  • Content count

    293
  • Joined

  • Last visited

Community Reputation

365 Neutral

About b34r

  • Rank
    Member
  1. Quote:Original post by IrYoKu1 IMHO it seems not to be so much faster. Our MLAA approach here runs a 1080p image in ~1ms in the same GPU. But it all depends how much less from 1ms takes NFAA (in the post says <1ms =) Nice, I was not aware of a practical GPU implementation of MLAA. The variant of an AA filter I proposed in the NFAA thread is basically 9 (very localized) texture fetch and I think that it can be reduced to 8 samples with no visual difference. I would not be surprised if it could very easily be brought down to 4 samples and weighting with a bit of brainstorming. I would have liked to try this 1ms MLAA but it does not seem to be public?
  2. You can check this thread for a much faster alternative to MLAA for deferred renderers. On the topic of the Z-prepass I'd like to add that you have to take in account the batch count of your scene. A Z-prepass implies an additional run through your batches which can be very expensive. If you have very careful artists with a strong discipline you might be ok but batches are in my experience the #1 worst performance enemy in a standard game scenario and they can quickly add up the more you add passes. It is not always possible to efficiently merge tri-strips/lists under a few giant A-only draw calls due to transformation, alpha textures, etc...
  3. Hi, Very nice results! Unfortunately I could not reproduce them no matter how. So I came up with my own version of your filter. It requires slightly less samples and still gives very good results. I made a blog entry about it and here is the GLSL filter. w controls the width of the filter (how large the edges will get) and the threshold (hard-coded comparison to 1.0/6.0) prevents over blurring edges that might not need it. float lumRGB(vec3 v) { return dot(v, vec3(0.212, 0.716, 0.072)); } void main() { vec2 UV = gl_FragCoord.xy * inverse_buffer_size; float w = 1.75; float t = lumRGB(texture2D(source, UV + vec2(0.0, -1.0) * w * inverse_buffer_size).xyz), l = lumRGB(texture2D(source, UV + vec2(-1.0, 0.0) * w * inverse_buffer_size).xyz), r = lumRGB(texture2D(source, UV + vec2(1.0, 0.0) * w * inverse_buffer_size).xyz), b = lumRGB(texture2D(source, UV + vec2(0.0, 1.0) * w * inverse_buffer_size).xyz); vec2 n = vec2(-(t - b), r - l); float nl = length(n); if (nl < (1.0 / 16.0)) gl_FragColor = texture2D(source, UV); else { n *= inverse_buffer_size / nl; vec4 o = texture2D(source, UV), t0 = texture2D(source, UV + n * 0.5) * 0.9, t1 = texture2D(source, UV - n * 0.5) * 0.9, t2 = texture2D(source, UV + n) * 0.75, t3 = texture2D(source, UV - n) * 0.75; gl_FragColor = (o + t0 + t1 + t2 + t3) / 4.3; } } Btw, I played with temporal anti-aliasing and there really is something great to be done on this front too. The main issue to solve is about how to combine jittered frames without introducing too much ghosting artifacts. Cheers
  4. Quote:Original post by WillC I work 9 to 5.30, 5 days a week, with 5 weeks holiday a year. I get a reasonable salary, with completion bonuses and royalties on unit sales (and since these are games that sell millions of copies, the royalties are good). Disclaimer: This an honest inquiry do not take it as flaming please. Are you working on major systems? >PS2 or PC? The only people I know with these working conditions are in the mobile industry. Well, I also know people in the mobile industry working 12 hours a day. Royalties on unit sales is almost a thing of the past even for lead coders in very small studios so what you are speaking of sounds close to a dream deal ;).
  5. Quote:Original post by Anonymous Poster I'm in sort of the same position as the original poster. Except I've just been layed off after five years of a "traditional" software engineering job. I'm not married and not hurting financially, so I'm just contemplating my next career move. I'm an avid gamer, and have always been very interested in 3D graphics, games programming, etc. I'm currently learning DirectX. I have 11 REAL years of software engineering experience, almost exclusively C++. My question: Is the game industry worth looking into, and do I have any real chance as someone with very solid software engineering experience, but no real game programming experience? If you have some good things to show in one or more game related fields then you probably have your chances, of course. You just need concrete things to show, it will always be much easier. As a software engineer with your experience expect to be severely p1ssed off by the code you will have to work on. If you want a good example of how bad it can get just have an honest look at the 3DS MAX SDK. I'm sure you have already seen plenty of poor code but MAX is pretty much a reference in very poor software engineering. IMHO passion is one of the worst thing that can bring you into this industry these days. Your passion will get burned in a few months. This is a buissness, no time for passion... unfortunately.
  6. From my own experience and the fairly large number of people I know in the industry I'd say that some companies are not like that but most are. Small or large developers, even the grunt worker is over 10 hours a day and a good number of week end spent working due to frequently missed deadlines. This is imho a very bad industry, avoid if you can. Of course, ymmv but probably won't.
  7. JigLib physics - new version

    Quote:Original post by MrRowl Quote:Original post by b34r edit: Just played a bit more, removing deactivation and setting physic frequency to 30hz and it's really stable... I wanted to improve the behaviour outside of the 1g, 60Hz, 1m box range. For example, it handles boxes with sizes ranging from 2cm to 5m. More than that the mass is so big the impulse calculation fails with floats. At the small end I think I have 1cm hard-coded in the collision system somewhere (e.g. for combining contact points) - I'll root it out! It can be better, but it's certainly a lot better in this regard than the older jiglib. I'm having troubles especially with low frequencies. Above 50hz centimeter wide bodies work acceptably, at 30hz: no luck. That jittering I can't get rid of. When I get a chance to, I'll add contact depth sorting and reimplement a working contact averaging. Btw, are you using contact averaging or simply sequencial processing?
  8. JigLib physics - new version

    It looks very good and it's not slow, even on my laptop (pentium M@1.76). Really good work :). I didn't spot any odd behavior, there's a bit of drifting in stacks but really nothing bad (imho). Well, I hope I can find time to write some more collision primitive :) you seem to have a nice collection already. About contact caching, I did get a small improvement with the cache only (ie. correcting contacts positions) but the biggest improvement came from handling static contacts with a point/point constraint. However, I think that you have much less drifting than I do without contact caching + contact constraint so you may not even need it. Looks quite useable to me already, you just need composite collision shapes. Not a big deal ;). Good job again! PS: I really like the colors of the huge pyramid in the AVI :). edit: Just played a bit more, removing deactivation and setting physic frequency to 30hz and it's really stable... amazing...
  9. Appropriate physics library?

    Quote:Original post by jovani Hey I am not fighting with you and I am not evangelizing anything. I used ODE and Tokomak before. ODE exact solver is too prompt to blow up and the iterative solvers of both aren’t stable enough for mechanical articulated bodies. Also I am not twisting anything either, you were the one who said the fps is 0.0000000647576 fps and I thought that, that was an exaggeration since this is the equivalent to 174 days per frame of animation. Even if the frame counter says that, it can not possible be true edit: My apologies, today has been a bad day and I'm certainly to blame for putting the discussion in such a bad shape. Well, glad to read that you are not fighting me. I explicitely said many times that I consider Newton to be a very good engine. That doesn't mean it's perfect and will fit all situations. At least, not yet. Of course a frame won't take that long to compute but dropping over 100 cubes in Newton Playground does bring my computer to a halt (ctrl+alt+suppr to kill the app). Surely this is a problem worth pointing out? [Edited by - b34r on August 2, 2005 1:38:54 PM]
  10. Appropriate physics library?

    Quote:Original post by jovani [...] Just what exactly am I supposed to say now? You obviously will twist whatever I might write to take it the wrong way. You see evil where there is none. As for the personal stuff, it's perfectly uncalled for and full of inexact assumptions... edit: It appears that you must be some kind of Newton evangelist. I don't need marketing ninjas messing with my free time. [Edited by - b34r on August 2, 2005 10:16:11 AM]
  11. Appropriate physics library?

    Quote:Original post by jovani about Newton this: http://www.physicsengine.com/forum/viewtopic.php?t=1491&start=0 seems faster than 0.00001 frame per secunds to me. I won't take the pain to reboot into Windows to provide a screenshot but if I have to, well, I will. I'm not saying that freely. I really like Newton but the point is that with the current version of the Newton Playground 99 bodies are above 60fps and 100 bodies are around 0.0000000647576fps. Don't know, don't care why. It's my experience with it. There's nothing wrong about showing that it's not the case anymore but just don't make it look like I and others are making things up. That's not nice.
  12. Appropriate physics library?

    Quote:Original post by visage Well, I don't know why I didn't announce my purpose for the system...that was dumb of me...but I am going to use it for my particle system, which will play a very big part in my game. Particle collision is really what is necessary. I will be making the particles as big as possible, when I can, but they might get quite small. The game will be 2d, so that should help cut down a lot of the calculations. Thousands is probably an exaggeration...but I would like it to be handle at least 100 at a time. Culling isn't really a possibility, because those particles that would be culled will be in the same sphere anyway. I think Newton is the one I am going to choose, as I am developing on a Mac. Any other thoughts, people? Thanks for the help so far. Well, I imagine you have reasons for choosing an existing solution but Newton (or any other 3d package for that matter) will be overkill. Also, as mentionned earlier Newton really drops from >60fps to 0.00001fps as soon as the object count goes above 100. I have no idea why but this will certainly be a problem. It's a very good library otherwise but you'd better check on their forums if that problem has a known work-around before making your decision. I know that Novodex has a mode especially designed for particles (no rotational effect) as do Tokamak. But, ok, displaying a couple thousand 2d particles is doable. You still need to be very careful because it's not that trivial. But it can be done. Good luck :). aftethought: If you are going to have 2000+ 2d particles on screen you should skip the particle/particle test altogether. From experience it won't look good unless you mean to model something like rocks etc... 2d particles with collision enabled really bring out the 2d constraint (you can tell it's 2d since you loose most of the parralax effect) plus it's usualy quite messy :). [Edited by - b34r on August 2, 2005 1:21:23 AM]
  13. Simple swept collision idea

    Considering how easy the separating theorem is, your idea is probably not as easy as you think. At least, it is much more involved and probably a great order of magnitude slower too... But if it works, it works ;). For a complete test as you describe, I seem to remember reading that you need to test the face barycentre aswell but I don't remember the details sorry...
  14. Appropriate physics library?

    While a specialized collision system using SSE and what's not may be able to run a few thousand dynamic spheres on a 3ghz system I doubt you will find a full physic solution able to do that. And sphere/box is a little bit more involved. AFAIK Novodex is the fastest around and I'm pretty sure it can't do that without its magic board :). Not to mention that you will have to design a pretty efficient culling system because the graphic system is going to have a hard time displaying that too... All I can think of is look into OPCODE, this might be a good place to start. From there design a simple mobile physic system on top of OPCODE, this should run pretty fast. Note: I'm assuming you want a fully dynamic system, ie: a couple thousand spheres at once, falling from a cliff, etc...
  15. Torque (and maybe NovodeX)

    Quote:Original post by ricekrispyw OK. Thanks. How 'bout the increased friction thing. Do you think that would simulate the reaction effectively? I wouldn't expect too much from general purpose physic engines when you are looking for accurate reproduction of a specific model. Most physic engine devs will for example recommand that you use rays to model a car so that you can handle tire/road interaction in a specific way. Even people using solvers that are known to be very accurate will ressort to this kind of 'tricks' because both the physic models and the collision modeling are incomplete. For your particular example since a tennis ball is not a rigid body it might prove very difficult to tweak the simulator so that it gives plausible output for a given set of input parameters (be it the terrain material, the ball material, wind etc)...