Thread: New screenshots from engine

ah, bum lol. Well anyway, just fyi iv found imageshack.us to be a good host for images, though i have only used avatars and sigs thus far.

Originally Posted by Bubba

Rotating objects to match their velocity vector
Now I know how to compute a velocity vector from one point in space to another, but I'm not sure how to actually rotate the object to match the given vector orientation. Just simply using the normalized vector components for rotation does not work. The normalized vector will always fall in the range 0 to 1.0f, but the D3DXRotation functions expect a value from -PI to PI.

Try just rotating on the axis proportionaly to their unit vector of velocity
uv.x * pi/2
uv.y * pi/2
uv.z * pi/2

Bubba, not sure if you saw my post in the other thread, but here is the relevant part of it:

Originally Posted by Hunter2

Code:

if (laser->Properties.LifeTimer>laser->Properties.LifeDistance)
{
if (laser!=Lasers.end())
{

This just seems somewhat odd, since you're checking if the iterator is valid AFTER you've already dereferenced it, but I assume that you're already aware of this.

From what I see in your code, every time you delete a laser, the iterator will skip the next laser: You delete the laser, assign the iterator to the next laser, and then you hit the end of the loop and the iterator increments again; thus you've skipped the laser in between. So if you have an odd number of iterators:

0) You have 3 elements
1) Delete element 0, iterator now points to element 0 (previously element 1)
2) Do something with element 0, increment iterator; now points to element 1 (formerly 2)
0b) You now have 2 elements, iterator points to element 1 (last)
1b) Delete this element, iterator now points to end
2b) If iterator != end, do nothing; increment iterator; now points 1 beyond end
0c) You now have 1 element, iterator points beyond the end of the sequence (still != end).
1c) Try to dereference it, and BOOM! kablooey, your loop crashes.

One quick solution I can think of is, stick it in a while loop and do the iterator management by hand (if you erase an element, don't increment iterator).

I hope that's the solution to your problem I ran into that some time ago, couldn't figure out why my various bullets/lasers travelled at different speeds in Space Shooterz.

So when you erase the object don't do lasers++? Okay then what does the current laser point to. According to the STL it would point to the next object..........nevermind I just figured out what you were saying. A big bright light came on in that last sentence.

Since it points to the next one in the list, the iterator has implicitly already been incremented. When my loop then iterates it again....I've skipped an object in the vector.

Thanks a million. I will try it out ASAP.


I've also come across another solution to the skybox code. I originally started with a sky sphere but decided it took way too many triangles just to produce a nice space backdrop. Then I moved to a skybox which takes only 12 triangles and 6 textures but it takes a lot more indices since duplicating texture coords at the vertexes results in very weird texturing. Since the vertexes overlap you must specify all of them independently because they all hold different texture coords. Try it and you will see.

Now I've come across another idea from my book Real Time Rendering by Moller and Haines. Instead of using a skybox I could use a simple textured quad at the far clip plane and to simluate scrolling I just translate the texture u,v coords. Since I've already done this in Direct3D with my terrain engine to achieve moving clouds I can readily use that class.

So my space backdrop will actually just be a huge quad that is drawn first with the correct texture coords based on camera's orientation. Then I draw everything else on top of this. It's similar to my sun glare quad and in fact will use a derivation of this class. The sun glare is drawn last and alpha blended with the destination image which produces a nice bright glare on the screen. What this new technique will enable me to do is produce one large texture and simply scroll it on the quad. It also allows me to use fog such as when your spacecraft is in a nebula and I WON'T get those ugly fog artifacts associated with skyboxes. Try it. When you fog a skybox too far into the distance...the fog builds up in the corners of your skybox and basically your corner's stick out like sore thumbs. This completely destroys the illusion you are trying to create with the skybox.

I think I might actually gain some frames with this method as well. I'm eliminating 10 very large triangles and 5 textures. I also do not have to compute any rotation values (except for perhaps Z which would be a simple 2D rotation of the u,v coords) which also saves CPU cycles. No translation, no world matrix, etc., etc. Also I won't get the perspective problem associated with skyboxes. You must create special textures or change the texture mapping to eliminate the perspective distortion in your skybox which is a pain. Perspective is what you want in 3D, but not in a skybox. It doesn't look cool when the left and right sides of the box are skewed due to perspective. It just doesn't look good at all.

Will have screenies shortly. Prob won't scrap the skybox code and in fact I still have the skysphere code - just in case I don't like the new technique.

EDIT:

HURRAH!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!HURRAH!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

I changed the vector code to use a while loop, only incremented the iterator if I was not erasing an object..............and it works beautifully. All lasers are updated correctly and destroyed as well. So what was basically going on was the old-fashioned array bounds overrun...with an STL flavor to it. I'm going to change my sound system code to fix this bug as well. Thats probably why my SAFE_RELEASE(Segment) is crashing so hard. It's probably a result of the vector fragging memory and then screwing something else up totally unrelated to it. Don't ya love C++?

Again..............thanks a million, billion, trillion. You just fixed my project and allowed me to correctly use vectors.............for lots of other stuff.

You da man!!

Always glad to help I remember, this particular bug had me stumped for about a month; when pairs of lasers were fired in parallel, mysteriously the ones on the left would begin to pull ahead of the ones on the right. I later realized that the problem was, when the lasers go off the screen they get erased.. but then that skips one laser in my loop, which also happens to handle movement. Thus as a laser is erased, another one falls behind by one frame.

I was quite puzzled for a long time

So, since you've got this crazy graphics engine and all.. are you going to be taking into account the delay that it takes for light to reach you over long distances, and time distortion as you approach the speed of light? Or light-bending effects of a blackhole?

J/k, looks really good.. keep it up!

The blackhole will not trap light since light is what makes 3D - well 3D. If I kill the light the game is useless. I might alter the ambient light as you approach the hole...but I'm not sure.

I thought blackholes bend light too, if the light goes too close to it without going past the event horizon? And then there's the whole space-time distortion mumbo jumbo It sure would be neat if looking at the blackhole, you instead saw something behind you.

>>Force=(O1mass-O2mass)*G/(distance^2)
Isn't it Fg = G(mass1)(mass2)/dist^2?