zBase (32bpp base set by Zephyris)

Zephyris · **Joined:** Wed May 16, 2007 4:59 pm **Posts:** 2624

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.

Zephyris · **Joined:** Wed May 16, 2007 4:59 pm **Posts:** 2624

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!

Michi_cc · **Posted:** Sun Jul 22, 2012 12:41 pm

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

Zephyris · **Joined:** Wed May 16, 2007 4:59 pm **Posts:** 2624

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

GeekToo · **Joined:** Sun Jun 03, 2007 10:22 pm **Posts:** 949

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.

CargoLiner · **Joined:** Thu Jul 12, 2012 3:42 pm **Posts:** 13

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

Zephyris · **Joined:** Wed May 16, 2007 4:59 pm **Posts:** 2624

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:

Quote:

% 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?

planetmaker · **Posted:** Mon Jul 23, 2012 7:44 am

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

Code:

[paths]
default = ssh://ottdc@mz.openttdcoop.org:22/hg-repos/zbase
default-push = ssh://ottdc@mz.openttdcoop.org:22/hg-repos/zbase

LeXa2 · **Posted:** Mon Jul 23, 2012 8:14 am

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.

Zephyris · **Joined:** Wed May 16, 2007 4:59 pm **Posts:** 2624

Cool, ill give that a go.

CargoLiner · **Joined:** Thu Jul 12, 2012 3:42 pm **Posts:** 13

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

Zephyris · **Joined:** Wed May 16, 2007 4:59 pm **Posts:** 2624

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!

Xotic750 · **Posted:** Mon Jul 23, 2012 4:23 pm

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.

Code:

GIMP Palette
Name: ttd-newgrf-32cc1only
Columns: 16
#
 20  52 124   Index 200

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

Code:

GIMP Palette
Name: ttd-newgrf-cc1only
Columns: 16
#
  8  24  88   Index 198
 12  36 104   Index 199
 20  52 124   Index 200
 28  68 140   Index 201
 40  92 164   Index 202
 56 120 188   Index 203
 72 152 216   Index 204
100 172 224   Index 205

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.

Xotic750 · **Posted:** Mon Jul 23, 2012 4:25 pm

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

Zephyris · **Joined:** Wed May 16, 2007 4:59 pm **Posts:** 2624

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...

CargoLiner · **Joined:** Thu Jul 12, 2012 3:42 pm **Posts:** 13

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

Alberth · **Posted:** Tue Jul 24, 2012 8:56 am

Is the road that deadly?

Attachment:

deadly_road.png [ 166.85 KiB | Viewed 820 times ]

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

Lord Aro · **Posted:** Tue Jul 24, 2012 9:56 pm

Need to adjust your monitor settings, i think

planetmaker · **Posted:** Tue Jul 24, 2012 10:30 pm

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)

Zephyris · **Joined:** Wed May 16, 2007 4:59 pm **Posts:** 2624

Yeah, I haven't made a tiled roof texture yet

I will work on that later.

Transport Tycoon Forums

zBase (32bpp base set by Zephyris)

Who is online