Transport Tycoon Forums

Michi_cc wrote:A flat ground tile at normal zoom has 64 pixels across and 31 pixels from top to bottom. A raised/lowered corner has an offset of +/- 8 pixels compared to the flat corner.

That suggests 8*(2^0.5)/(32*2)=0.1767, which is actually slightly too short... Anyway I have remade the temperate terrain tiles with a corner height of 0.2 (reduced from 0.25) which I think should work better. These are in the repo for testing anyway.

Nailed the maths Camera angle is 30 degrees, tile width from the camera POV is 2^0.5, slope height relative to tile width is 1/8th, therefore 3D slope height is (2^0.5)/(8*cos(30)=0.204156

I will update all the terrain sprites, it would be cool to see them coded to check I have done all the calculations right!

Zephyris wrote:Camera angle is 30 degrees

Sure about that? The pixel sprites use a two pixels left, one up approach, which would result in an angle of 26.565°. But of course, if the result works, then it works

-- Michael Lutz

Michi_cc wrote: Sure about that? The pixel sprites use a two pixels left, one up approach, which would result in an angle of 26.565°. But of course, if the result works, then it works

It messes with your brain trying to work it out The diagonal 2px along/1px up line lies at atan(1/2)=26.565 deg from horizontal, but that's not the same angle the 3D camera should look at the scene. It took me a long time (and some trial and error!) to work that the camera needs to be looking down at 30 degrees to give that result.

I hate geometry :s

Zephyris wrote:

Michi_cc wrote: Sure about that? The pixel sprites use a two pixels left, one up approach, which would result in an angle of 26.565°. But of course, if the result works, then it works

It messes with your brain trying to work it out The diagonal 2px along/1px up line lies at atan(1/2)=26.565 deg from horizontal, but that's not the same angle the 3D camera should look at the scene. It took me a long time (and some trial and error!) to work that the camera needs to be looking down at 30 degrees to give that result.

I hate geometry :s

Zephyris is right, Michi_cc too (kind of) but for the wrong view. The 26,56° is the angle between game x and y axis in the resulting plane. Ratio x:y = 2:1, which means an angle of arctan(0,5) = 26,56°. But that is not what Zephyris wanted, he wants the angle to rotate the groundplane (or camera angle whatever you want) so in the view plane y of tile is half the x. So seen from the side, perpendicular to the camera and ground plane the question was: how much to rotate the ground tile so the y is half its full size. We know the tile is square, so to obtain half the y, we need to rotate the tile so sin(alpha) is 0,5 (alpha measured between line from cam to centre of ground plane and the line throuhg the ground tile). Then the answer is arcsin (0,5) = 30 degrees, or 60 degrees from vertical.

at times like this i would just do a screen grab and do a camera match

I'm having difficulties pushing some changes to the server;

I set up TortoiseHg (on Windows 7) according to this guide: http://dev.openttdcoop.org/attachments/ ... _0.9.0.pdf

I am trying to push quite a big change set (~100Mb) but TortoiseHg gives an URLError, this is the log:

% hg --repository M:\zbase\zbase push https://zephyris@push.openttdcoop.org/zbase
pushing to https://zephyris@push.openttdcoop.org/zbase
searching for changes
URLError: [Errno 10054] An existing connection was forcibly closed by the remote host
[command returned code 255 Mon Jul 23 07:52:47 2012]
zbase%

Does anyone know what this could be?

Zephyris wrote:I'm having difficulties pushing some changes to the server;(...)

I'm not 100% sure, but it might seem that it's the same or a similar problem that pulling big repositories via http fails currently

You could try to configure pushing the changeset via ssh (same path as you have configured for pull) in the hgrc

hg uses http post or web/dav (depending on server configuration) to send data from client to server. In case you're pushing something really big you might hit http connection time limit. I hadn't been ever using openttdcoop repos so I don't known for sure what the real limits there are, but you could try configuring your client to use ssh (like planetmaker advised) instead of http(s) and see if that helps.

Cool, ill give that a go.

Zephyris

Just wondering why you do not use a Material ID pass to isolate company color mask


although seeing as these are 8bit files without alpha a slightly better setup might be


this was achieved by assigning the material CC_Normal a pass index of 1

I certainly could do. The reason I didn't is because a plain colour pass is simpler and therefore more flexible when trying to return multiple 'special' colours; some objects have CC, some have a recolourable brown colour (bridges, some buildings), some have a recolourable green colour (grass on road and rail), etc. Blender can't produce 8bpp paletted render outputs anyway so some post-processing of the mask sprites will always be needed so the colour pass approach is essentially equivalent anyway.

If it completely fails it would be fairly easy to switch to a material index pass too though... Maybe I will work that into the render noodle now in case it proves useful!

I am using a slightly different method for OpenGFX+ Trains.

I use a material index and compositor block in a similar fashion for the 1cc and 2cc but do not mix the background colour into it.

I set the material colour to a central value in the 8-bit colour range.

This produces 2 files with alpha in the correct 8-bit colour range.

This allows me to do a few post-processing tasks; making the 8-bit CC masks for 32bpp and also creating 8bpp sprites.

Using GIMP, I then convert each mask to a single colour using an index file, for example to get the 1cc mask for 32bpp I use, but you can change this to lighten or darken the sprite's CC colour.
Finally, I add 3 images together:

1. The backround colour (magic blue)
2. The 1cc image
3. The 2cc image

This gives me an 8-bit image mask for the 32bpp sprites, as shown below.



For the 8bpp sprites, I again use the 2 image files created in the compositor and the image without ground shadows (another compositor block, the shadows look awful in 8bpp within OpenTTD) and pass them through GIMP. This time I use a colour index file containing all the 8bpp cc colours

Now what I do here is that I take the sprite image, convert it to DOS indexed without any special colours (i.e. flashing colours etc), this does not give me a final image because the CC magic colours are not good after this process. So, I now take the converted masks and lay them upon this image and finally merge down.

This gives a nice 8bpp sprite with the correct cc colourings, as shown in my example below.

Yes, quite a bit of post-processing in GIMP and maybe too complex for some of the more structural sprites, but works great for vehicles.

You can find all of this in the OpenGFX+ Trains repo, or PM me if you want any further info.

planetmaker wrote:You could try to configure pushing the changeset via ssh (same path as you have configured for pull) in the hgrc

Just giving this a go, I assume I need to give my public key to someone...

would it not be possible to spit the V from a HSVA into a color ramp mapped to the CC index colors masked off to the Material Index (your probably going need to eye the spacing but it should still give decent enough results)


Multiple special color mask can then be mix back to a single image

Is the road that deadly? Edit: For me the church roof is invisible, so the cross seems to float mid-road

Need to adjust your monitor settings, i think

Alberth wrote:Is the road that deadly?
Edit: For me the church roof is invisible, so the cross seems to float mid-road

Oh, I wondered first what you meant
(I see the church roof: same colour but different brightnesses)

Yeah, I haven't made a tiled roof texture yet I will work on that later.