this is something that's been on my mind but I can't find much information on this on Google (which leads me to believe that it's probably not a good idea if nobody else has thought of it).
Umm... okay say I have a scene with a bunch of enemies and other moving models. And I want to implement localized damage (shoot enemy in the foot, or in the shoulder, etc... specific places).
Is there any reason I can't do this by using GL_SELECT rendering mode in an auxiliary buffer? like when a shot is fired, render everything like normal as always, but then, in an unseen auxiliary buffer, switch the "camera" to your gun's point-of-view, and then draw the models to the namebuffer (remember this is GL_SELECT rendering mode so things like textures, lighting, even regular won't cause overhead because they're not drawn -- just flat polygons with "names" associated with them). And then if there's any hits in the auxiliary buffer upon a shot, take the identity of the hit polygon and figure out which body part of a model got hit?
this probably is useless for true collision (as in physics, bouncing, etc) but I thought it might be a neat solution to registering bullet-shots on dynamic entities in a scene.
You'd be rendering the scene twice, which is pretty WRONG. Although on modern hardware, writing a shitty game, you can probably get away with something like this, there are more elegant ways to model the movement and collision of fast-moving objects like bullets. I think that most games use ray-casting for this sort of thing, which is where you represent the path of the bullet with a ray and then perform collision detection on that. Note that performing a ray-intersection test with every triangle in a scene is hardly realistic, so you might want to use bounding spheres, for example, as an optimization.
Also >>3
Name:
Anonymous2006-09-06 18:16
I didn't know you could do raytracing in Opengl except to draw 2D pixels. Links please.
Name:
Anonymous2006-09-06 19:37
>>5
Raytracing doesn't involve OpenGL, you just create a ray in the direction the bullet is travelling and calculate the time it will intersect objects in the scene, lowest t is the one it hits.
Yes you can do it that way, and yes it's fairly slow. As for determining what to do as the result of a collision, depending on the system you're using it may or may not be of use.
Another shitty way of doing it is rendering the scene to the back buffer with solid colors then flipping a single pixel to the front buffer and seeing what color it is.
An alternative to this is the excellent ColDet library which will do this sort of thing better, or Open Dynamics Engine which is a full physics simulator but rather complex to use.
Or you can always use the common vector approximations like boxes, cylinders, and spheres - they're simple enough to write - but I personally can't stand games that use them as they are too inaccurate.
>>28
It's better then having a page full of friggin Satori threads
Name:
Anonymous2007-07-05 8:09 ID:63su+Kz4
As a newcomer to /prog/, I have been somewhat astonished by these old threads that actually discuss programming.
Name:
Anonymous2007-07-05 11:03 ID:JjXoQzQ2
>>30
Yes, /prog had a bit more quality in the past as far as discussion goes, but it can be more fun now. Ever since it became the new /VIP, we've been outdoing ourselves every week.
Yet I wouldn't mind serious discussion as long as we can make funny references to memes in every post.
Name:
Anonymous2007-07-05 11:47 ID:jsoSUfQe
>>32
wiichan.net/c
Wherein Anal Touring posts an ircd written in Python.
Name:
Anonymous2009-01-14 13:13
SICP
Name:
Anonymous2009-01-31 11:20
As a newcomer to /prog/, I have been somewhat astonished by these old threads that actually discuss programming.
Name:
Anonymous2009-01-31 11:24
>>34
discuss programming?
why the hell would we want to do that?
Name:
Anonymous2009-01-31 12:09
>>35
Especially since most of /prog/ is at the stack pointermonadicoverflow level.
Name:
Anonymous2009-01-31 12:13
As a ɹǝɯoɔʍǝu to /prog/, I'm still somewhat astonished by these old threads that discuss inane programming ideas like they were worth discussing.
Name:
Anonymous2009-01-31 12:19
It's better then having a page full of friggin Satori threads
OMFG FFFFFFFFFFFFFFFFFFFFF *rage* XD
Bringing /prog/ back to its people
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy