Smart Cam Problems
Blitz3D Forums/Blitz3D Programming/Smart Cam Problems
| ||
| I'm writing up a Solar System Tour program and I'm running into some trouble that I hope someone can help out with. I'm using Anthony's Smart Cam code found in the CodeArchives. I just dont understand the usages of TFormVector and TFormX and the like so I cant quite follow his code. I've done a few searches with those keywords with no good hits so I'm left in the dark on what those mean and exactly what those do. Blitzs lacking help file mentions vector's, but i'm even MORE at a loss with that. I'd alway thought these commands had something to do with terraforming and working with vertices. Anyway, the problem I'm having is that when I send the smart cam after something extremly small (.1 - .000001) that it get very jittery and bouncy. I'm guessing that at that small size its losing accuracy on where its looking and going somehow. Anyone got any suggestions on how I could fix this? The scales are that small because of the way the solar system is. Pluto is 6 billion kilometers out, some moons are only 8 kilometers big .. for whatever reason if I ratio pluto's distance to where its more than 1000 out from sun then I get screwy effects. This means I have to use a ratio of 10,000,000 : 1 for distance, which also effect size. A moon or planet with a 1000 km radius suddenly just went to a size of .00001 ... Leda is only 8 km across = .00000008 Space is just so big I lose either way. |
| ||
| Your definately loosing floating point accuracy which explains the jittering. Other people have tried to recreate a solar system and run into the same problems due to scale. Imagine you have spaceship flying around the solar system .. One possible way to resolve the problem is to store all the x,y,z global positions of each object, including the spaceship but positionentity each entity relative to the spaceship as it moves ... so the ship is always at world coords 0,0,0. Not sure if I explained that right but it's a bit like a tilemap in 2d - hopefully you get the jist. |
| ||
| At first I thought that sounded like a mad crazy change in program to accomplish, but after more searching I found a relevant link that explains the process of "Normalizing". This helped me to better understand what I'm going to need to do. Thanks for getting me pointed in the right direction Stevie G! Here's the link I found that explains the idea and provides some code. I'll give this a go and then let ya know how it works out. http://www.blitzcoder.com/cgi-bin/ubb-cgi/postdisplay.cgi?forum=Forum4&topic=000352 |
| ||
| WEll... I'd propose another solution BEcasue I ebt you still ahve rpoblems :P (we programmers always have rpobelms, you know) This is an algorthm Id eveloped 1 decade ago on good old QuickBAsic 4.5 (tm I think) .... I create an array of supspaces (a big space contains a series of supspaces) those supspaces are a partition of the collection. (that means no subspace shares anything between, no rpeated space, but all compelte the space. I recomend multiples of 3 for each of the idmensions: 3*3*3 boxes form the unveerse, which would be 27 boxes, I'd recomend 12*12*12 for the first layer. Now you can use -relative- coordinates to the center of each subspace. Whe your ship travels, you need to load 27 subspaces at once (the one you're on all and the surrounders) each coordinate woudl now be of 4 components, x,y,z and Subspace. If numebrs are still to big, I recomend a largesubs ystem of 30*30*30 or a second layer of subspaces, which would be more complicated. a mutidmiensional array could use a subspace of 60000,60000,60000 with no problems (except RAM, that'd be LOTS of MB) 120*120*120 should suffice. I hope someone undrstands mi blabbering. |
| ||
| Hey Stevie, just an update. I've managed to get things working a bit. Still got some tinkering to do to tie up loose ends and whatnot, but I think its licked. I just flew to the outer reaches of Pluto with the resolution set pretty high and the jittering was gone. Here is the code I got that someone else may find of use if the previous link should come up dead. Huge HUGE thanks to Andy! Function housekeeping() ;Call this function from your main loop as often as you need it ; to "Normalize" your environment. This is used to keep your environment ; moving while you remain the center of the universe and not suffer ; from the loss of floating point accuracy and weird effects from moving ; too far from 0,0,0 location. Rather than using controls to move the ; player, use them to move all your stuff around them! ;'Camera' should be your "player" pivot ;'MasterPivot' is the pivot your universe is tied to. Or you can run a loop ; to move all your entities if they arent tied to a single pivot. ;HUGE thanks to Andy at Blitzcoder for this function. fieldsize#=2000 mmx = 0.0 mmy = 0.0 mmz = 0.0 If EntityX(Camera,True)>fieldsize Then PositionEntity Camera,EntityX(Camera,True)-fieldsize,EntityY(Camera,True),EntityZ(Camera,True) mmx = -fieldsize : mmy = 0.0 : mmz = 0.0 MoveEntity MasterPivot,mmx,mmy,mmz EndIf If EntityZ(Camera,True)>fieldsize Then PositionEntity Camera,EntityX(Camera,True),EntityY(Camera,True),EntityZ(Camera,True)-fieldsize mmx = 0.0 : mmy = 0.0 : mmz = -fieldsize MoveEntity MasterPivot,mmx,mmy,mmz EndIf If EntityX(Camera,True)<-fieldsize Then PositionEntity Camera,EntityX(Camera,True)+fieldsize,EntityY(Camera,True),EntityZ(Camera,True) mmx = fieldsize : mmy = 0.0 : mmz = 0.0 MoveEntity MasterPivot,mmx,mmy,mmz EndIf If EntityZ(Camera,True)<-fieldsize Then PositionEntity Camera,EntityX(Camera,True),EntityY(Camera,True),EntityZ(Camera,True)+fieldsize mmx = 0.0 : mmy = 0.0 : mmz = fieldsize MoveEntity MasterPivot,mmx,mmy,mmz EndIf End Function ;housekeeping |
| ||
| Heh kalimon, you must have posted as I was writing mine out, didnt see yours till just now. Maybe I didnt quite understand what you where saying? It sounds like a rougher version of what Stevie suggested and what I'm currently going with. However you've defined specific zones or regions to pass thru? I really like housekeeping because I can tie everything to a single pivot to be moved and I need only exchange my movement controls from controling the player/observer with that central pivot and my whole program is still intact. I dont mean to belittle your suggestion, I just dont fully comprehend it. Heh, the suggestion of moving my universe around the player rather than vice versa gave me a brain ache the first time I read it. |
| ||
| It's not moving the universe.... you jsut have 3 coords od ship x y z, supose 30*30*30 bxes compound the universe sized 10000,10000,10000 so you just load 27 pivots each one with a small distance between them and your ship. distance to objecto woudl be signed distance ship-pivot + signed distance pivot-object. dividing the universe into sveral minr pieces coudl give you 3 more decimals per dimension (1000,1000,1000 divisions subspace) whicih I think is what you are missing by using regular numbers. |
| ||
| kalimon, in theory your idea sounds like a hugely complicated procedure that I dont quite understand how to correctly go about. Without some kind of example code or something for me to actually see what you are talking about I wouldn't be able to even attempt what you suggest. Remember, I'm working in 3d space using all 3 coordinates. A buddy of mine thought that what you proposed might only work for a 2d environment. Stevie, I've fully implemented the idea of moving the universe around the player. I've tried 2 different variations. Variation 1 was to keep the player locked at 0,0,0 and move everything else thru the use of a single MasterPivot. Variation 2 took the approach outlined by Andy and Nmuta on Blitzcoder and still moving the player, but then normalizing (i think correct use of the term) everything back to 0,0,0 when the player went a set range from that point. Both variations work in a limited sense. Being around the planets/moons/sun now has no graphical artifacts or weird effects, however I do still get those weird effects from objects that are far away and still visible such as Orbit Lines (Torus meshes I use to represent the planets orbital path) Space is big and moving too fast is a problem. While moving out to far far distances the "speed" or how much you move sometimes is greater than the distance in which I normalize. This leads to space flickering, blacking out, and then after I stop "catching up". At first I thought I could use that as a "hyperspace" effect, but without full control of gfx and effects you just dont know how its going to look on other computers. I'm still tinkering until I either : a) find a better method b) solve the problems c) give up I want to work on gfx and effects so bad right now, but I don't want to waste my time if I can't work out the basic underlying mechanics. |
| ||
| Hi Folks, When you get to these excessive speeds, why not kick in a separate 'grey space' effect? Later, Jes |
| ||
| Well I also suggest to change the FOV of the camera. Aslo make speed in inverse function of gravity, the cosest and the bigger the obejct is, the slower you move: speed= MAxspeed- (sum off all (distance of obejct from ship *mass) /(amount of obejcts *adjuster) adjuster depends on maxspeed nad minimum speed you desire. also an imprved speed funciton: maxspeed- max(minspeed,(sum off all (distance of obejct from ship *mass) /(amount of obejcts *adjuster) ) I espect this one to be easier :D the other one is compelx indeed. But looks floats will work good enough for you. (this algorythm I rpesented days back is a ogood sibstitute for creating a woel BIg numbers sysem for floats, but you don't need it at the end. |
| ||
| Hey I didn't see this thread until now.... >Huge HUGE thanks to Andy! You are welcome, but the concept isn't my invention. I lifted it from the AMOS 3D manual back on the Amiga. >however I do still get those weird effects from objects >that are far away and still visible such as Orbit Lines >(Torus meshes I use to represent the planets orbital path) Have you considered dual pass rendering for longer view distances? near#=1.0 intermediate#=5000.0 far#=1000000.0 ;far CameraRange cam,intermediate#,far# CameraClsMode cam,1,1 RenderWorld frameTween ;near CameraRange cam,near#,intermediate#+500 CameraClsMode cam,0,1 RenderWorld frameTween ;The overlap is to compensate for how B3D renders terrains with LOD etc... It shouldn't be needed for a meshes only world. Change the near/far range to something larger... Dual rendering is, however, very costly in graphics rendering time. Andy |
| ||
| Another thing you could do, is to change the near/far range to reflect the closest and furthest object... Basically just calculate the distance from the camera to every object and set the near value to the closest distance-something and the far value to the furthest distance-something. Something being the width of the largest object in the game. In the code above, you write: 'Rather than using controls to move the player, use them to move all your stuff around them!' Just remember that calling it every frame is redundant, CPU intensive and can lead to problems with collision. Andy |
| ||
| Thanks for the feedback everyone! I've managed to actually get things working well together now. My sollution to the moving too fast thing was to call the Housekeeping() function redundantly until it brought things back under control. There is no noticeable effect or loss of framerate from doing this and the camera can move from the outter orbit of Sedna (about 90 billion km away) back to Sol in about 5 seconds. Course this is on my computer - wait till i get a workable version for others to try and see what kind of headaches i get hehe Pluto being only 6 billion km out can be traversed in about 2-3 seconds. I'm not sure out that smart cam works its speed, but it seems the farther you are the faster it runs heh. Thanks for the ideas Andy. I'll give those a go and let you know how it works out. Thanks for all the help everyone! I've run into another small snafu that I'll stick in a seperate post to keep things topically correct. |
   |