Rotatable Camera View

[Kickme93]

Suggestion Rotatable Camera View

This Is A Suggestion, How About A Rotatable Camera? I Am Sick Of Online Seeing The Trains In The Same View..

Can We Rotate It?

[yorick]

No, We Can't, Because OpenTTD Is Not A 3D Game, But 2D, So Everyone Has To Draw A Rotated Version Of His Graphics And That's Not Gonna Happen. Dev's Have Also Said That OpenTTD Won't Be 3D, Ever.

But did you know about the transparency menu? You can access it by pressing Ctrl-X.

[LordAzamath]

aaaa... It hurts my eyes if someone is demanding something .. This Is A Free Project, Nobody Gets Paid, So Noone Cares If You Get Sick Of Trains In One View..
ok.. Sorry for capitalizing, I realised it's ugly

[athanasios]

...Everyone Has To Draw A Rotated Version Of His Graphics And That's Not Gonna Happen.

If someone draws the standard sprites rotated, it can happen. But I don't believe anyone will do it.

[Zephyris]

It depends how good the rotation is wanted to be - 90 degree map rotations would be relatively easy to make graphics for, but smooth rotation (which I think OP is suggesting) would not.

[Kickme93]

Just Your Occasional 360 Degree Rotation So You Can See All Views Would Be Good

(Btw... Im Not Demanding It Its A Suggestion)

[yorick]

Could You Stop Capitalizing Every Word You Say Thank You.
Now: as I said, and as I now have a quote of:

We won’t be doing a 3D version.

The graphics we as OpenTTD will supply, will always be close to TT graphics. We are not going renegade with some other kind of look and feel. We like TT as it is. (period!)

[athanasios]

"360 Degree Rotation"

We already have that!!!

[yoyo1505]

3D idea aside, I've noticed that due to the way all the new 32bpp graphics are drawn they can be viewed from any angle. So theoretically, in the far far future where 32bpp is finished, it would be possible to do a SimCity style 4 viewing angle (e.g. from N, E, S and W) feature because all the sprites could potentially have appropriate views for each angle.

It's half possible at the moment with 8bpp but unfortunately only the vehicle and infrastructure sprites have the alternate angles to work with.

Is it worth putting the effort in when 32bpp is finished to add this feature?

[FooBar]

"360 Degree Rotation"

We already have that!!!

Yes, you can use the 'any key' to enable it

[Th3Eagle]

In order to do this the entire game engine will have to be rewritten, i don;t realy see this happening :S

Keep in mind that the 32bpp replacements are indeed moddeld 3d, but when that done they take screen caps in different direction so that it can be used in this game. Don't fooled, the game looks a bit 3D because of the "view point". But its completly 2d drawn!!

[athanasios]

Some people tried to make a 3D OpenTTD but they remained in words. Project is dead.

[Zephyris]

It got further than words! But then:

It will have no aircrafts, ships, road vehicles, rail on slopes, vehicle reliability, scenarios, economy windows, subsidies, authorities, music, linux support etc.

That kinda put me off...

Having said that I can still make good models and textures, and Blender's getting some nice UV normal mapping updates next release...

[GeekToo]

OpenTTD is still very far away from rotable views. Like said before, the graphics core code is completely 2D oriented.

Besides the question what 3-D views are going to add to the gameplay ( I have serious doubts about that) I think that there is a more important step to make:

Create a blitter that uses OpenGL: this can show 2D views, but uses the graphics hardware to zoom in/out etc. Recently I made a performance profile, and it showed that about 50% of the processing time is put into drawing the graphics. When this would be done on the graphics card ( and almost everybodies graphics card is capable of that nowadays), this would mean a huge performance improvement. When that step is made ( big code change imo ), the next step might be going to 3D.

[DaleStan]

When this would be done on the graphics card ( and almost everybodies graphics card is capable of that nowadays),

Except for the minor detail that graphics cards today don't draw sprites. They draw lotsandlots of triangles with one of a few textures.

Many rail sets now-a-days have ~10k sprites. AIUI, each of those would have to be loaded as a separate texture, unless you manage to get Open to decompose the sprites into textured triangles.

[GeekToo]

Except for the minor detail that graphics cards today don't draw sprites. They draw lotsandlots of triangles with one of a few textures.

If you make a true 3d model, that would be true. But you can setup a non perspective view in OpenGL, define a quad, and assign a texture to that. If the texture would be the current sprite data ( i.e. the RGBA data ), the hardware would take care of the pixel manipulating when zooming and redrawing, instead of redrawing every pixel in every frame like the current blitters do. That would mean no more quads than there are sprites.

Many rail sets now-a-days have ~10k sprites. AIUI, each of those would have to be loaded as a separate texture, unless you manage to get Open to decompose the sprites into textured triangles.

With the current blitter, the 10k of sprites RGB data has to be loaded too, so that would make no difference. The big difference would be what you do with that data aferwards: draw every pixel of that data into video memory over and over again, or assign it to a texture and let the graphics card do the pixel manipulation. After all, a textured quad is not really different from a sprite ('billboarding'). As I mentioned in the previous post, that would mean a big code change, but it is possible.

[DaleStan]

Many rail sets now-a-days have ~10k sprites. AIUI, each of those would have to be loaded as a separate texture, unless you manage to get Open to decompose the sprites into textured triangles.

With the current blitter, the 10k of sprites RGB data has to be loaded too,

Unless you're playing full screen, in which case it should be using 8bpp, not 32.
And can today's video cards deal with 10k textures for the rail vehicles, probably 6-8k for road vehicles, a good 5k of default old stuff, 1k or so for ships, 2k for planes, and 5-8k each for stations, industries, and town buildings? (For a total of over 32k.)

[doktorhonig]

I think, it would be manageable if you have a texture for each direction of a list of vehicles, 256 vehicles in one texture, as a 16x16 vehicle matrix. There are lots of possibilities to put more things into one texture, and if a z-Buffer is used, you can even save a huge amount of texture-switches like drawing a train, then some trees and then a house in front of that.

Some people tried to make a 3D OpenTTD but they remained in words. Project is dead.

I think, OpenTTD would be just as dead, if existing TTD and TTDPatch graphics could not be used.

[GeekToo]

And can today's video cards deal with 10k textures for the rail vehicles, probably 6-8k for road vehicles, a good 5k of default old stuff, 1k or so for ships, 2k for planes, and 5-8k each for stations, industries, and town buildings? (For a total of over 32k.)

I assume you are referring to the size of the texture data, not the amount of textures here?
Then I see no reason why that amount of data cannot be handled by video cards. These days, video cards are pretty powerful, and even older cards have 4 Mb of memory, so 32 kb should not be a problem.

If you're referring to the number of textures, I've never seen a screen in OpenTTD where 10.000 sprites are present for rail vehicles at the same time.

And as doktorhonig stated correctly, there are ways to limit the number of textures.

[Zephyris]

Overhead in 3d rendering is the number of meshes and the number of textures; number of meshes = number of sprites, which is unavoidable, unless you start doing clever things like rendering terrain as a single mesh. Use of large textures containing may sprites would alleviate some of the overhead from number of textures. all in all it does kinda seem pointless, the devices this will run on that have opengl (ie. computers) are powerfull enough for this optimisation not to be critical.