|
Socoder -> Blitz -> Number accuracy or snapping objects together |
|
| Mon, 26 May 2008, 09:01 | |
Forklift_Fred
|
I'm including an example so you can see what I'm dealing with but the theory is simple (aren't they always?!) I'm trying to make a Scalextric based slot car racer. I've made the track pieces precisely in 3ds format and done the maths required to position the next piece yet 9 times out of 10 tracks that should work, don't line up  They are normally close and you could see that in reality it would be possible (Anyone with experience would know that flexibility works wonders in the real world) but in some cases I have entered track designs from other design software that work perfectly. The pieces themselves aren't the problem because the positioning is done numerically by an x,y offset and a rotation as specified. I started off calculating the curve offsets in Blitz but it was pathetically inaccurate and resulted in about 2mm difference in each axis (baring in mind I used a straight 1:1 scale) I went back and calculated everything manually and it improved greatly. The problem has to be Blitz's accuracy with decimals but I have seen other track design screenshots that have the same issue (see pic below) If it were just a designer for the real world it wouldn't matter but I want to race virtual cars around my virtual tracks! What advice can you guys give me? The writer of the official Scalextric designer had problems getting pieces to 'snap' together but from what I read, his solution was the same as mine. It got me thinking about snapping though, is there a way to do it in Blitz? Scalextric demo (The slx files define the offset and can be opened in notepad. Only the first line is read but the second is the calculations that Blitz gave me originaly - I just didn't delete them!)   On the left is someone else's work with my version next to it. On the right is the curve details You'll see the first track piece is red and the second is green, just so you know where you are. You can zoom in and out with 7 and 8 (number pad) as well as move (8,4,6,2) and arrows to rotate (badly!) Does any of this make enough sense for you to give advice? 
-=-=- Come rain or shine... |
| Mon, 26 May 2008, 10:22 | |
JL235
|
I don't quite fully understand what the problem is, but in relation to the accuracy of Blitz, why not use another language? For precise measurements you don't use floats, you use doubles. For more precise measurements you special classes that provides greater accuracy. You use them during the calculations so that rounding errors are not compounded, and then convert to a float on use. But I'm not suggesting you turn completely away from Blitz. You could build a program in something else to more accurately calculate the values you need and then save them to a file that you could read back in from Blitz. Alternatively you could make the calculation functions in C++ and compile to a .dll. You give it your values, it does more accurate calculations, returns a correct result. |
| Mon, 26 May 2008, 11:39 | |
|
Forklift_Fred
|
Thanks but Blitz is what I have, it's what I use. It's not so much the calculations that are the problem because I've pre-calculated myself so using an alternative language for that part is irrelevant, I'm giving it more accurate numbers. I think I'm fighting a pointless battle, to be fair. This is probably more of a rant than anything The alternative I touched on is to snap the pieces together. I can place them very close to where they need to be but is there an easy way to shift them to close the slight gap? The first vertices should, ideally, be in exactly the same place as the last vertices of the previous piece. -=-=- Come rain or shine... |
| Mon, 26 May 2008, 13:18 | |
shroom_monk
|
Forklift_Fred  The first vertices should, ideally, be in exactly the same place as the last vertices of the previous piece. Haven't read you first post, but from the quote above, couldn't you just calculate the distance between the vertex of the first and second track parts, then move the object by that distance? -=-=- A mushroom a day keeps the doctor away... Keep It Simple, Shroom! |
| Mon, 26 May 2008, 14:06 | |
Orion Pax
|
You could do something like this if you know which vert it is. Now what I would do is open up my modeling program and position the MOST BOTTOM LEFT Vert at 0,0,0. And when I say bottom left vert I mean in view of being on it...so when you go around the track the idea will still line up. Now you can use the above code to find the top left vertex and line up your next mesh with this This should almost work. The only thing I can think of that would keep this from working is that it will put your meshes on top of each other on that ONE LINE crossing Xloc,Yloc,Zloc. Basically the edges of both will over lap by 1 point in space. But this is the closest thing I can come up with. And its dangerously close. |edit| Oh and the count commands are purposely put in for no reason as blitz seems to require them to be called before the others will work. I think. I have fount that the gfxdriver and gfxmode commands in blitz wont work unless you use their count command counterparts first. |edit| 
|
| Mon, 26 May 2008, 15:37 | |
Jayenkai
|
Yeah, like Cucco says, on a real Scalextric the tracks probably wouldn't line up precisely.. If you tried to set them perfectly on a real one, they probably wouldn't fit, either. Remember, when you're connecting the two end points, you usually have to tweak it. When you do that, every little track piece shifts a teensy tiny bit to fit. My guess is that, when the tracks bend back and forth, it creates a small size discrepancy. Since you AND someone else have had the exact same problem, this more than likely isn't a problem with the maths, it's going to be something else, and that's probably what it is.. -=-=- ''Load, Next List!''
|
| Mon, 26 May 2008, 16:15 | |
|
Forklift_Fred
|
Sounds like a bad idea to try and make it in Blitz then... OK, well this has all given me things to think about so thank you all. I guess I'll either tray and fail or I'll cheat and succeed... I'll let you know... Cheers -=-=- Come rain or shine... |
| Tue, 27 May 2008, 08:29 | |
|
Paul |
Could you take all the pieces of track to make one large mesh? Or maybe scale everything up a little? |
| Tue, 27 May 2008, 09:26 | |
|
mindstorm8191 |
I don't know how much this would help you, but if you consider how engineers design bridges these days, you have to deal with shifting points sometimes. Try desigining your track sections with just a bit of overhang on both ends, that dips down a bit. Then any gaps in the accurate placement of your pieces will be filled with this overhang. And if it is accurate, then your overhang will simply be underneath the next track section.
-=-=- Vesuvius web game
|
| Tue, 27 May 2008, 11:29 | |
|
Forklift_Fred
|
I could certainly make it as one mesh but the idea was to have a track editor. The overhang idea isn't all bad but the biggest problem wouldn't be solved, that of misalignment. I could easily close a gap with an extra straight section but if they are not in line (like my example) then it's no help. I thought of a 'magic' piece this afternoon, whereby you would say "Close Track" and it would put in a straight piece and adjust the vertices to line up, assuming it's not too far. I might also look at other brands of slotted track because they use different sizes... I may still encounter the same problem though. -=-=- Come rain or shine... |
| Tue, 27 May 2008, 14:50 | |
|
Jayenkai
|
The "Fixer" solution seems to be the best.. Have a big button that says "Click-it!" or something, and at the end of building, it'll figure out the misalignment, and then go through, and alter each of the curves a teensy tiny bit so that the misalignment is reduced to 0. At this point, I should point out that this is pretty much what stopped my Twisty Turny Wipeout esque track designer.. They never seemed to meet up. Should be easier to do with a 2D track than my complex twisting looping freaking-out mental tracks, though! -=-=- ''Load, Next List!''
|
| Tue, 27 May 2008, 15:33 | |
|
Orion Pax
|
OT: I was wondering what happend to that. I thought you were still working on it. I was hoping to see that one to its end. Oh well. I never saw any misalignments on yours. Back on topic. Will my suggestion now work? Or are you saying that the pieces are slighty getting deformed as they are twisted and warped?
|
| Wed, 28 May 2008, 12:31 | |
|
Forklift_Fred
|
Sorry, I read your code and almost fainted with fear I wasn't sure about the idea of positioning bottom left at 0,0,0 and the code meant nothing to me... Looking at it calmly now and referring to the help files I think I see what it's doing. I might look into it deeper, it could help with the 'magic' closing piece. At the moment, I started with some VERY basic tracks and they lined up perfectly. I then started adding curves and making sure they balanced out... Again, they lined up perfectly. Problems started to creep in when I had straights that weren't parallel or perpendicular to each other... in fairness, it makes sense that this would be the route of the problems. It looks like everything is working how it should but we wouldn't notice the slight adjustments in reality as discussed above. There is still one track design that looks like it works in theory but not in practice but at least I know where I stand. Moving on, do you think I'll actually be able to use the slots to guide the cars around? I'd expect more headaches but in theory sliding collisions should do the job shouldn't they? Thanks again everyone! -=-=- Come rain or shine... |
| Wed, 28 May 2008, 14:51 | |
|
Jayenkai
|
In theory (but that's not working great so far!) yes, the slots should do their job. Stick a stick on the cars, like a real Scalextric, and the collision detection should ensure the stick stays inside the grove. Turning the cars might be an issue, though.. -=-=- ''Load, Next List!''
|
| Wed, 28 May 2008, 15:43 | |
|
Orion Pax
|
What that first code box does is find the location of the vert where the next peice needs to line up with. Then the second box just positions the mesh where that vert is at. And if you moved your meshes MOST BOTTOM LEFT VERTEX to 0,0,0 in your mesh editor and then re-export them. This should line them perfectly. Now like Jay says, the slot collision should work, but turning the cars will be an issue and I cant seem to think of a solution. Unless you implement some sort of path finding node network or something. Or what you could do is when your slot cars stick collides with the piece that has the turn in it make a secondary loop that will slowly turn the car so many degree's each loop with speed in mind. The faster the car is going the faster the turning is. Does any one get the idea? LOL
|
| Wed, 28 May 2008, 16:54 | |
|
Forklift_Fred
|
Well, I'm off work tomorrow so apart from a trip to the dentist I should get some reasonable time with this. I'm actually quite happy with the way the track is laying out now so all I really need to worry about is closing any silly gaps, probably using the sloping-down-over-hang idea and working out the cheating 'magic' section. I took some time this evening to implement some editor functions because working purely with track piece numbers was hell! I can now click on the images at the top to add pieces (or press Enter to repeat the last piece) and press Backspace to delete the last piece. All very useful when trying to close a track, especially when you can see when a quick left-right will step it across just enough  I also impressed myself by implementing SaveTrack() and OpenTrack() functions I also want to be able to insert part way along and change existing pieces but both of these will require a recalculation. Perfectly achievable but I'll have to decide how to navigate back along the track... actually, that should be easy enough using Before and highlighting the current piece... I was thinking of using the mouse but that could get tricky. Sorry, I'm just thinking aloud now  With so many areas, I don't know what to work on now
-=-=- Come rain or shine... |
| Wed, 28 May 2008, 17:21 | |
|
Orion Pax
|
I would suggest just finishing up the track problems. once the layout is 100% working then just randomly choose each option to work on I Guess....or go in order of importance. I like the random idea.
|
| Wed, 28 May 2008, 19:47 | |
|
mindstorm8191 |
Jay: at one point I was considering creating a F-Zero-X style game, with wild tracks. Instead of building-block style pieces, I had planned on having a spline-style line represent the track, and from point to point you could specify the track's roll, width, bent in or out (or all the way around), etc. I didn't end up getting anywhere with it though. Maybe I should've... sorry for being off-topic -=-=- Vesuvius web game
|
| Thu, 29 May 2008, 04:53 | |
|
Forklift_Fred
|
I'm wondering about splines myself actually. The slot method is working to a point, it is the turning that is starting to give me headaches. I thought using CollisionNY() would give me a good angle to turn through and it was if I doubled it but then when the track bends to the left, it still turns right! Perhaps I could compare current and previous positions instead... I think you're right that I should get the track handling sorted first but I need to know how the movements going to work before looking at making a track-piece that doesn't have fixed parameters - I need to know what sort of parameters need changing
-=-=- Come rain or shine... |
| Thu, 29 May 2008, 08:17 | |
|
Orion Pax
|
Hey fred, do this....each piece is still its own entity right? Test the collisions for turning against each piece individually. Like make a seperate function for each piece to test collision with it and the cars. If it has collided then turn. You will only have to test collisions against pieces that curve. Straight pieces you wont have to. |edit| Oh and let me ask.... CollisionNY() - Returns the y component of the normal of a particular collision. What is a NORMAL? |edit|
|
| Thu, 29 May 2008, 08:18 | |
|
Forklift_Fred
|
OK, after much head scratching and desk thumping, I have a working track-follower. I tried using ATan2(new_z-old_z,new_x-old_x) but for some reason it just went mad so I scrolled through the command references and came across VectorYaw()... Sorted! The PositionEntity is to stop it sliding up though I will need to change this if I ever add slopes to allow crossovers... I think I need to add 90 to the VectorYaw() because I'm moving along x rather than y but that may change when I make the models properly. I have since realised that ATan2() was spot on, but I was using TurnEntity() instead of RotateEntity()!!!! I've now gone back to ATan2 because it only uses EntityX() and EntityZ()
-=-=- Come rain or shine... |
| Thu, 29 May 2008, 11:26 | |
|
Orion Pax
|
Oh and let me ask.... CollisionNY() - Returns the y component of the normal of a particular collision. What is a NORMAL?
|
| Thu, 29 May 2008, 12:29 | |
|
Forklift_Fred
|
en.wikipedia.org/wiki/Surface_normal It refers to the direction that a surface is facing. I'm not sure how they work in Blitz but I imagine it is something like this... Imagine a piece of wood with a nail in it, at a perfect right angle. That nail represents the NORMAL of the wood's surface. I think the x,y,z components probably refer to the end of the nail, assuming the nail is exactly 1 unit long. This means that I was probably using it wrong earlier I'm now having problems getting LinePick() to identify which section the car is on |edit| It sorted itself out somehow! |edit| -=-=- Come rain or shine... |
| Thu, 29 May 2008, 15:23 | |
Orion Pax
|
Yeah blitz has a habit of doing that.
|
|
|
| |||
|
| ||||