Path: chuka.playstation.co.uk!news From: rs108@mdx.ac.uk (Robert Swan) Newsgroups: scee.yaroze.programming.3d_graphics Subject: Re: strange results - please me Date: Tue, 26 May 1998 22:21:12 GMT Organization: PlayStation Net Yaroze (SCEE) Lines: 60 Message-ID: <356b3cab.9329540@www.playstation.co.uk> References: <35696395.3682283@www.playstation.co.uk> <01bd8801$161a2940$1e3863c3@default> <3569f00e.14217704@www.playstation.co.uk> <01bd88e1$14c1b460$77e16dc0@ulthar.han.de> NNTP-Posting-Host: th-eng12-230.pool.dircon.co.uk X-Newsreader: Forte Free Agent 1.11/32.235 The way my track works is like this. Imagine a loop made up of 600-odd sections on track. The idea is that if on piece 100, it will only draw pieces 100-200. This is what is stored in fs1 and fe1 (in this case fs1 'forward looking start 1' = 100 and fe1 'forward looking end 1' = 200). Complications occur because - 1) when you are near the end of the track (say 600 out of 650) then you want to draw pieces 600 to 650, and 0 to 50, and this is what fs2 and fe2 are, a second list of drawing things. I could have just wrapped a drawing value from 650 back to 0, but didnt bother, because of - 2) where the track splits. If left as it is, when it reaches the split it will happily draw the left branch up until the left branch ends, at which point it goes back and draws the right branch. What you really want is it to draw both paths when approaching it, until you have definately selected one of the paths, at which point it will only draw that path. This requires two sets of drawing lists for these sections of track. That is what the code I was adding was doing (and it worked). 3) as it turns out, if im at section 100 i actually want to draw 95 - 195 to avoid premature dissappearence of objects close to the camera. (pop-down?) I think point 2 is what you noticed in my array, sections of track from around 48 onwards includes the split up track, and 288 is where the second branch starts. What I will do is actually check out whether its drawing those correctly, although ultimately like you said, it just affects whether or not it gets drawn, not its orientation. The results of this problem are twofold - each piece of track is oriented incorrectly, suggesting a problem with my tCurrentOrientation variable - which shouldnt exist because it is not affected by the new code I added. Also, if it was just that, then the track would not form an almost perfect loop as it does, as each piece of track would be out more and more (as the position of the next piece of track is based on the previous one's tCurrentOrientation), but if you compare both examples, the second one is only slightly out. So the differences are - in correct version 1 all pieces of track are opriented correctly all pieces of track are positioned correctly in incorrect version 2 all pieces of track are oriented incorrectly by a relatively large amount all pieces of track are positioned incorrectly by a relatively tiny amount. Im so confused - Robert Swan rs108@mdx.ac.uk http://www.netyaroze-europe.com/~middex2/ftp/HELPME.ZIP first prize for person helping me - first copies of my tmd modeller - editor on the yaroze :)