I have just started the Wonder Wheel as my next major project, so far I do not have to much to show but here it is anyway.



I am not sure if this really looks like the Wonder Wheel as the designs I have do not allow me to see enough detail. So tell me what needs to be fixed. You may also notice I am working on a basic side project the "Wave Swinger", this is just for me to go to if I grow slightly bored with the wheel.

All ideas and thoughts are welcome.

Thats very interesting, I never knew that. Thanks for filling me in, at least now I understand the fundamentals of the ride and the height. I will fix this up a bit later. One other thing are those middle sliding car just sliding on a suspended cable.

Ok thanks sebar, I'll try and fix it now.

I have been thinking about this ride and have decided to put it on hold for a while. I still do not think I know enough about it. Also the polycount will be enormous, if anyone else wants to have a try at it that has seen the ride or has a better understnading of it then feel free to.

Thanks for that sebar, that has helped heaps. But now I am stuck with how the support structure is in the middle.

I'm wondering if the cars for the wonder wheel can be the same as ones I'm tinkering with for a gondola ride?

That is great the hope of the FRCS that cars and pieces from different rides can be mixed and matched in order to create variations of rides, in much the same way that real ride manufacturers drop different pieces of fibreglass over the mechanics to theme the same ride for different parks.

Whilst the gondola ride does come under the tracked ride category, there is no reason that the gondola mesh can't be reused in the FRCS and I've gone to great pains within the code to structure it so that the same instance of a mesh can be used with different textures, without having to import the mesh multiple times.

The whole point of the frcs is to be able to reuse parts for different rides, otherwise people could just fully create a ride in their modeller. Nobody says all parts have to be reused though.

It's another argument where both sides are actually right.

Sebar, you are correct in that there are certain "historic" rides which have very specific shapes, however there is nothing to stop those shapes being used with a different arrangement of hubs and pivots to create a completely fantastical ride.

Somewhere in the system there is going to be a big long list of things like cars, struts and other bits which could be used to create almost anything by sticking them together. The way that those bits are arranged is a template that can then be stored for use at a later date.

Elsewhere in the system will be a long list of the above templates that can be accessed to allow a pre-assembled FRCS creation to be dropped straight into the environment.

Don't you see? This concept completely abolishes the idea of an "ovl". Everything that's needed is the parts library (of which I think no one said it needs to be hardcoded) and the template.
This doesn't mean we cannot provide functionality to take all needed parts and the template and zip it up for independant distribution, but those won't be directly used in the program, it will extract the parts, include them in it's libary and forget about the transfer pack.

If you don't need new parts for it, just send him the template. If it includes special parts, The FRCS will pack it into a package format (zip for example). TPB3D will open that, put the new parts into it's part library and add the template as a new flat ride.
It remains to be seen as what animations and textures will qualify, pieces of the template or a kind of part of their own.

Arrrr!

Skip would be proud... ;]

I see talk of texturing. This leads me to wonder how that will happen unless all texture are laid out in a certain order.

I was thinking, though: would it be possible to have automatic texture scaling/tiling? I'm thinking of an animated texture for the cable in a skyride- if the cable's mesh can be stretched and tilted up/down, the game should be able to remap the texture based on a formula: if the base mesh X=64 and X gets stretched to 256, then the texture map tiles X 4 times. Something like this might be useful for altering size of the various models.

Apologies, I must have missed this one, when Vodhin posted in July.

Texture animation should be possible. It's not been coded, but the structure is in place to allow a sequence of textures to be linked to an interpolation, thus allowing the sequence to be started, stopped, rolled backwards, etc...

OpenGL can be told to tile textures.

A distinction needs to be made between scaling models and procedurally generating something. Scaling is a linear translation applied at the GPU level that stretches everything, it cannot remap texture coordinates. Procedurally generating something (or re-generating if it's been modified) recreates a mesh from scratch therefore it can modify the texture coordinates to realign the texture tiling. Potentially tiling could be recalculated on the fly at the card level through a custom shader but I've not investigated that possibility enough to say whether it possible and the cost/benefit ratio isn't high.

Okay WC, here is the original Wonderwheel posting we set up. The top cook comments are about obsoleted so you can go from there. Good luck on this long sought after project. It has been waiting for a very longtime.

Ok cool... I'll try to slam it out... Might need to rely heavily on our texture crew for the inner, and outter spokes... That alone will kill thousands of possible polys...

Don't want that damned parrot getting after me... lol