Quote:
I think I confused a few thing. From Marcel's post, I gathered that the mesh is modified while running (similiar to a mipmap) to make it more detailed. After reading you post and re-reading Marcel's post, it seems that I was wrong about that, and that there are instead two versions of the creation algorithm around, with one adding much more tesalation than the other. The model gets created at startup, and doesn't get modified anymore afterwards.In that case, there's absolutely no difference in performance wheather we create the geometry by algorithm or by hand (i.e. modeling software), since the finished mesh is dumped into memory either way. In that case I would strongly advise to make a nice model with a nice texture map.The only reasons there could be for generating a station procedurally is a) making every station look slightly different and b) adding more detail to the mesh as you aproach. Both mean runtime modification, and can be worthwhile if done well, but I really don't see the sense in creating a static mesh by algorithm. Humans usually do that a lot better.
hm...pioneers native scripted geometry will be always better for performance.i can't tell you why, but i have made enough models to compare between (i.e. cty3k exists as sripted geometry as well as made from objects), that i can tell that exactly from experience (and i fear that everything gets turned upside down, just that some rectify themselfes and some theory**).one reason could be that i can only project textures, there is no unfolding and no resulting per face texturing.if you arrange the geometry by texture and projection values, you gain some additional speed, imo.btw, the original "wheel" had fixed divisions, while i used LOD dynamic divisions for all parts of the "big crappy".and if you still don't believe, try to experiment rather to theorize.to me it counts only what FPS i got afterwards, where it may come from i don't mind (...to much, could be interesting to theorize about that, but didn't changes the result).some believe in theory, i believe in facts (results). i'm a construction worker, it doesn't matters what a paper says, but it matters much if it works out and lasts.or to tell in other words, i construct a pipeline without a balance and it's more straight as the one which is been made using a balance. in the end it's measured by the eye and not by a little air bubble.if i stamp decals and emboss them i could calculate the thickness of the material and set the machine up with this value, it never matches. i HAVE to tweak it with the eye (in the best case you can't see where it was embossed if the decal gets peeled off).of course we work here only with virtual things, but still to me the result is what counts.you can use also a texture on lowest lod, but don't be surprised if you get a weak performance....you can run with your head even through a wall, it will hurt i promise.... (i know that from experience too
)[/hr]if people are able to manipulate negatives of x-ray pictures from a uranium pellet, there are willing to manipulate anything, just to rectify something....
Set the threshold at something like 0.9 and it'll always pick something that's within a little cone along the direction you're pointing. If you happen to have multiple things under the mouse that's fine because it will always pick the one that the mouse is closest too visually regardless of depth/distance since everything is a normalised direction.No complicated scene traversal, bounding volume heirarchy tests etc. Just a few dot products, a min test and an if-else. You can probably optimise some of those away too if you're feeling fanatical 
That would be awesome beyond belief!@ potsmoke66, Thanks! I've got to get to that station, even though it's back there in alpha 15. Pioneer sure is a moving target, isn't it? :lol:I'm glad you said you welcome contributions from people of different skill levels, because I want to share what I've been working on, humble though it may be. It's an upgrade (or possibly a defacement) of Philbywhizz's pad stations. 
). but, i haven't had any good idea to solve that, except a giant texture that will cover the whole wheel from top view, common texture or glow-map.edit: wrong, a mapping only for the inside facing part would be enough (centrifugal force to the outside), but the torus had to be changed into a "lathe" perhaps, further sections of a tube/cylinder never match sections of a torus (one starts on the corner of the division the other on the center of the division)a soulution would be a complete rebuild of the torus[attachment=983:torus_1.jpg]the radar, was planned to be off center (as long that it's rotational axis is centered). well there are some disabled calls for a (updated) building of mine, i disabled to avoid complications and i thought perhaps some wouldn't like that, looks a bit weird).could be now that the nav-lights are really to fast, still i'm not able to run pioneer on the macbook* and the wrapper is far to slow (1-2 fps), i'm simply not able to tell if they are fast or slow (it's guesswork).maybe the green & red pos-lights are better left as they was before. it's more a experimental use here, to show that you can use a sine to control aflashing light. if the frequency is to slow it will show off a quite to long fade-in, fade-out. while on higher freq. it looks better then a immidiate change (rectangular signal), imo.[/hr]*"Error: Vorbis could not open data/sounds/Interface/OK.ogg"somebody's got any idea, do i miss something perhaps?