Member

64

205 Neutral

• Rank
Member

• Role
Programmer
• Interests
Programming
1. ## 2D vector graphics using shaders

Quote:Original post by Halifax2 Chapter 25 of GPU Gems 3 might be of interest to you: Rendering Vector Art on the GPU. Quote:Original post by raigan Rather than using circles, rectangles, etc. as primitives, you could use a single general/generic primitive, for instance beziers: Resolution Independent Curve Rendering using Programmable Graphics Hardware You could then build circles, rectangles, etc. by combining many of these simpler primitives. This is an area i have been attempting to look into as well. Have there been any implementations of these methods. i was attempting to work out the alpha-blending method mentioned for graphics cards that do not support the ddx/ddy gradient instructions. Although not entirely necessary for more recent cards, i would like to better understand the math involved, and would be nice to have support for it in those instances. Any help in that area would be greatly appreciated. Haven't compared against using distance fields yet though.
2. ## Exterior Ballistics

I am currently attempting to handle various effects present on bullets during flight. I have a fairly basic method in place using some simple bullet coefficient based drag models i found, but I am looking to find out more concrete informationon on handling the different characteristics of bullets and environmental factors that contribute to the way a bullet reacts when fired. I currently use a G1 drag function combined with gravity and a simple calculation for relative wind interference and combine the forces with the initial/current muzzle velocity and trajectory direction over time to compute the change in state as the bullet travels. I would like to find more information on how various ballistics calculators/simulations handle things like wind, altitude, temperature, bullet weight, ballistics coefficient, sighting, and other factors when computing the effects on a bullets trajectory in order to improve my current simulation. How is this traditionally handled in more realistic simulations and related situations? Any information, resources, and/or advice you could provide would be greatly appreciated. Thanks in advance.
3. ## Multiple contacts with V-Clip

I would also be interested in more information in this area. I am just getting into my own real investigations in collision detection methods and starting to look into both gjk and v-clip. More information on the detection/determination of multiple contact points would certainly be helpful. As well as any more clear information on these techniques and others that may be beneficial to experiment with.
4. ## Animation Blending

Hello, Are you still using the originally posted test code? Although if you only have a single track it won't matter (or at least won't see the problem), but to be completely accurate your Blend method would need to know the totalWeight before using the current tracks weight in the division. Adding it up as you go changes the ratio each time a new tracks weight is added. Also in your test code it appears you add two key values at time 0 and 1 (or 1 nd 2 - depending on the post), yet you increase the time value by using time++ which increments by 1 each time, skipping in between float values of time (try testing with keys at times 0 and 2 if you want to keep it like this). It's also probably best to ensure keys are within some valid time range regardless of the time passed, and disregard animations by some other means - use curr->value if time < curr->time, use next->value if time > next->time, depends on your needs I guess. bool FindKeys(Keyframe *& left, Keyframe *& right, real time) const { if (!keys.empty()) { KeyList::const_iterator curr = keys.begin(); KeyList::const_iterator next = curr; for(; next != keys.end(); ++next) { if((*next)->time > time) { break; } curr = next; } if (next == keys.end) { next = curr; } left = (*curr); right = (*next); return true; } return false; } Be mindful of any inaccuracies - treat more as a pseudo-code suggestion - depending on how you choose to handle things you may always want the true current and previous/next keys instead of them being the same key when the time is out of range. Other than that, from the quick glance I did I don't particularly see a direct solution to your issue. May need a few more clarifications on how exactly you are handling things.
5. ## Semi-Procedural Animation: Locomotion System Released Now

Glad to hear things went well with the presentation. This looks very interesting. The addition of support for quadruped characters is also of interest. Looking forward to learning more about the techniques used.
6. ## Chunked LOD + GeoMipMap without Skirts

As long as you don't mind being restricted to only 1 LOD difference between patches I have been able to get away without using skirts in my geomipmapping based implementation. I use a different triangulation of the regular patches than most seem to promote, preferring a layout similar to that which result when using triangle fans versus the more uniform structure. Another Post This helps simplify things as all my index buffers are static. I am still looking for even more ways I can improve upon this. With more than 1 level difference I agree it would probably get complicated keeping things matching up, but as of yet I haven't even looked into using skirts so far. Hope that helps.
7. ## Atmospheric Scattering from Space (O'Neil)

If you transform the points into world space you now have to take into account that the sample points may no longer relative to the origin. The shader code was taking advantage of the fact that points were relative to the origin to allow for them to just be normalized to get correct direction vectors. Once the planet is translated this is no longer the case. So you need to subtract the sample point from the new planet center for those directions and normalize that rather than just the sample point itself. This also goes for things like the light direction as well, as for objects like the sun the direction would actually be from the light position to the planet center, not just a static direction vector, as this would make the light appear to come from the same direction no matter where you placed the planet. You can also just make sure everything is in object space so that all your positions and direction are relative to the planet being centered at the origin. Hope that helps. [Edited by - Amadeus on July 31, 2008 8:39:15 AM]
8. ## A bit of history

Been following for a while, event before this IOTD...the good ol' days of flipcode. Always impressive since the beginning. A lot of very insightful information shared as well. Highly interested in seeing how it all turns out.

10. ## Atmospheric Scattering from Space (O'Neil)

That was with your original source, project modified to compile in Visual Studio 2005 instead of 2008, and the shader code i posted above. The only thing changed was the position of the camera. The planet is not being rendered in that shot, just the atmosphere. [Edited by - Amadeus on July 21, 2008 10:50:24 AM]
11. ## Atmospheric Scattering from Space (O'Neil)

Hmmm. This is what you should have seen with the shader as I had it. I also moved the camera position to (30, 0, 0), but that shouldn't have mattered since you could move around the planet.

13. ## Atmospheric Scattering from Space (O'Neil)

If I remember correctly, O'Neil does render the back faces of the atmosphere so that the inside of the sphere is showing (I missed this at first as well). Depending on your methods, this saves you a sphere intersection check as well since the vertices rendered consist of one side of the intersection. Though if you calculate all the intersections and distances correctly I believe it shouldn't matter. As well you need to discard the points that would have otherwise intersected the planet, either by calculating the intersection, and adjusting your distance, or rendering a sphere the size of your inner radius to cover them. As the cosine of your start angle appraoches -1 the x=1-fCos in expScale approaches 2, which makes the equation in the exp() call eventually reach approximately 22.919, and exp(22.919) is extremely large, as you have seen. The distance covered across the entire atmosphere, where the planet would otherwise be covering, is larger by comparison to the ones you get from horizon to horizon. Towards the center of the sphere the distance covered moves towards being the diameter of the sphere; also as the sample point starts to move through the "center" the angle between the sample and view/light directions increases causing the cosine of those angles to reverse. Since the scattering tends towards white at the horizon, and the planet/atmosphere diameter is much larger than the distance to the horizon, combined with the cosine reversal, you get white across the center of the sphere. Without handling intersections with the planet the distances will only be within a suitable range in the "relatively" small area of the atmosphere where the planet does not appear, which is why you see your "edges" appearing to look correct. Otherwise, rendering the planet with the same shader is actually what fills in the rest of what you see, as well as accounting for terrain color, etc. Hope I worded that right, and hope it makes sense. Feel free to correct me, heh. I'll try and take a look and see if I find anything else. [Edited by - Amadeus on July 17, 2008 7:21:40 AM]
14. ## AABB to sphere

If you assume the aabb is actually enclosed by a cube the size of your largest half axis, you should be able to multiply the largest half axis by the square-root of 3 and get a sphere radius that will enclose the cube. This may not be accurate enough for you if your aabb are far from being ideal cubes, but the sphere will surround the aabb. If you have a unit sphere centered at the origin, an aabb that encompasses it will have a corner at (1,1,1), whose distance from the origin is sqrt(1*1 + 1*1 + 1*1) = sqrt(3), which since the half axii are 1, mean that a sphere bounding the cube equals the sqrt(3) times any of the half axii. For non-cube aabb, taking a suggestion from a collision detection article a while back, whereby you divided the interacting variables by the half-axii to convert things from ellipsoid into unit-sphere space, multiplying your half-axii by the sqrt(3) will get you the relevant bounding ellipse instead. Dividing by the sqrt(3) will get you the enclosed sphere/cube or ellipse/aabb. In 2d this would be the sqrt(2) instead. I hope that makes sense. - revel8n [Edited by - Amadeus on June 16, 2008 1:35:20 PM]
15. ## Track IOTD Topics

Would it be possible to track IOTD topics like the other forum sections? I don't seem to be able to do this currently. Also are posts suppose to mark themselves as read just by visiting a forum section? Topics get marked as read just by me entering a section, not by having to actually enter the topic itself. Could there possibly be a way to categorize tracked topics? Thanks in advance.