Creating new textures for terrain painting

[cromerobrill]

Hi all,

I'm trying to create new textures for terrain painting. I create a textures.xml blueprint in my source tree Brill\Addon\Environment\Terrain. This xml file is a copy of the textures.xml file in Developer\Addon\Environment\Terrain and asset editor tells me that exportation is ok. I also have ticked Brill-Addon provider...

But I cannot see the texture for painting when i world editor. What am I doing wrong? Maybe this kind of blueprint is not intended for painting purposes? What is the kind of blueprint adequate?

Cheers

Carles Romero, "Brill"

[t1metraveller]

Hi Brill,

Unfortunately, in this game, terrain textures aren't like objects where you can select from either the European set or the US set or another developer.

Once a route is created, the terrain texture set is determined by the texture set specified in the particular route template used. If you use a US template, you get the US texture set. If you use "Default" or one of the European route template, you get the European texture set.

One of the guys created a combined texture set (texturing.bin file). It works, but then your route cannot be uploaded for others unless they have the same combined texture file.

So, until RSDL gets this sorted out, or not (I understand this was a design feature, to have dedicated texture sets), we will have to live with it or use combined terrain texture files. Not sure what their plan was for 3rd party textures. At this point in time, there is no mechanism to include 3rd party textures except by combining them with the game's default texturing.bin file.

Bill

[bigvern]

That's a blow - see other thread re the terrain textures from Cajon not being accessible if you choose the European set, even within the US version of the game where Cajon is supposedly a default route.

However I had relied upon being able to download a suitable sandy texture and add this under a "Vernstuff" or similar developer directory for use in the route. Not just sand but any different texture you might fancy using to get away from the default.

[AndiS]

There are two problems.

1) Mixing textures from different sources. In your case, your own plus one of the two default contents of KRS. As far as I understand, textures.bin is just a list of references to the actual textures. So all you need to do is expand the textures.bin file (using Mike's TMB) by a few entries for your textures.

2) Availability of the referenced textures. The combined EU & US textures.bin is only for people who own both versions of KRS or the expansion pack. This is why Vern is looking for alternative sand, to be used by Europeans without expansion pack. In your case, all you need to do is ship your texture files with the route.

However, people on the other side of the pond will not enjoy your route unless you add an alternative version using different textures, which is not likely. So the way to go in the medium term run is to have only freely available textures in your route and ship them all with the route, with a textures.bin exclusively referencing these.

[bigvern]

I assume textures.bin is a global file, not specific to a route?

If so then the next time they download another route with yet another third party set of textures that will remove mine from the list (or if they already have a route with an amended texture.bin, they will lose the reference when unpacking mine)?

And the whole process is hardly conducive to helping end users who may only be computer literate at the basic level, just want to plug and play so far as any add-ons are concerned!

[RSAdam]

Hi guys,

Careful not to make vastly sweeping statements about Rail Simulator without fulling understanding the mechanics at work. It can lead to all sorts of unnecessary negative conclusions as we have seen countless times. Terrain textures do not live in a global file that gets over written by each route you install.

[cromerobrill]

Hi all,

Thanks for the explanations. I had a wrong mental picture about texturing in RS. At this time I think I have reached my goal.

I edited the texturing.bin file in Assets\Kuju\RailSimulator\Environment\Terrain and I observed that all the texture files in it are full path referenced. Then I dessigned the following strategy:

1. I created a texture blueprint textures.bin containing only one texture (blue grass )

2. I exported it and I created and exported a template route blueprint referencing my textures.xml recently created.

I created a new route usint this template. Of course all the terrain appeared covered by blue grass. Only this blue grass was available for painting.

3. I renamed the file textures.bin to _textures bin.

4. I copied the file texturing.bin in Assets\Kuju\RailSimulator\Environment\Terrain to Assets\Brill\Addon\Environment\Terrain and renamed it to textures.bin

5. I edited this new textures.bin using KRS Bin Convert and added to it the section in _textures.bin (my old blueprint) referencing the blue grass.

Now all the default textures plus my new texture blue grass are available for painting!

These are my findings. Of course I would apreciate any criticism.

Best regards,

Carles Romero, "Brill"

[bigvern]

Hi guys,

Careful not to make vastly sweeping statements about Rail Simulator without fulling understanding the mechanics at work. It can lead to all sorts of unnecessary negative conclusions as we have seen countless times. Terrain textures do not live in a global file that gets over written by each route you install.

Any chance you can expand and clarify, please Adam?

There seems to be a fair bit of confusion with this one...

If I create some terrain textures of my own for use in a route can I:
1. How can I use them alongside the default textures without having to hack the textures.bin file?
2. When I package the route for export will they will display correctly in any recipients route without affecting any third party textures they may have in other routes.
Or:
3. If I wish to use my own textures, must I create a complete set of my own which have to be used exclusive of any others?

Making the textures is not the problem - there's plenty of source material out there and if all else fails the digital camera. Also, if I start a route with a texture set, can I add additional items to the palette as I go along or is it set in stone once the blueprint is run?

[AndiS]

Ok, so the answer is: Once you hacked your own textures.bin (along the lines of Carles' algorithm), and under the condition that you give the route a unique "product/addon" name (which you will certainly do), there is no problem. You ship your textures.bin which will not replace anything. It refers to any textures, some of which will sit in a nearby folder under the same product main directory, some will be found in the default content (if the downloader is lucky enough to have the right version of the game).

Still, question 1 looks like being answered "not without hacking", unless Adam pulls an unknown blueprint from his sleeve.

2. Textures of your route should not interfere with others as your route has its own textures.bin pointing to your textures, which are stored in your hierarchy. If someone else named his sand sand.bin, too, that other sand will be somewhere else (like AndiS/route1/.../sand.bin) and your route will have no reference to AndiS stuff anyway, and AndiS stuff will have no reference to your route.

3. You can reference other people's textures in your textures.bin, but of course, there is some risk that downloaders do not have them, which is only natural.

[t1metraveller]

This is what I have discovered in my testing.

For clarity, I'm going to call the texturing.bin file a texture "control" file, as it points to the texture set, which are the image textures themselves.

A route can reference only one texture "control" file, which is set up by the route blueprint. That file right now is either one of the default ones (texturing.bin, in RailSimulator or RailSimulatorUS), or it can be a texture control file you make yourself and pack up in a developer folder. I have done this for testing - for instance - combined the two texture control files, the UK and the US ones, and made one texture control file and placed it in a developer folder named "CombinedTextures". Then I made a route blueprint that references this developer texturing file.

Now, there is a slight bug when you start a route this way, using this route template, in that the first time the World Editor loads, there is no ground texture - the ground is blue. You then check the box to include the new developer texture set - which does nothing by the way - then close the World Editor. Restart the game and your combined textures appear and are available, and the ground is textured properly according to your new "developer" texture control file.

I would foresee for routes that have their own terrain textures, or a combination of default and unique terrain textures, them using their own texture control file in the developer folder structure. This would require the route designer to create a texture control file by the hacking method, to include all terrain textures that are necessary for the route, right? You would combine items out of the default control file (or just start with the entire default control file), then add the new terrain texture paths to this file as well, and pack it up with the route as a developer item in the developer folder.

The problem is - I'm sure the original design did not call for users to hack texture control files. Surely they would not think the route developer would be happy solely with one of the default texture sets? Provision has been made for new 3D objects, I would assume that provision has been made for new terrain textures, and a way to include them, yes?

So Adam, the question remains: what is the proper way to include new textures in a route? I'm sure the devs must have anticipated that the end user would want to do this, right?

Bill

[bigvern]

If there was an original "design" in this it seems to have been aimed at the payware developers who will naturally want to use their own texture set for EULA purposes, but then lock it down so it doesn't pop up in freeware routes.

Unfortunately that has left the poor freeware route designer faced with either using the existing default textures (and I don't recall there being that many) or making his own set but then having to write a bin file - which is bordering on programming - so they can be referenced in the blueprint. Neither MSTS or TRS require these steps - in MSTS you assembled your bmp's or tga's, converted them to Ace files and dropped them in the route texture folder. In TRS you crop the TGA file, assign a KUID number then either make a folder for it in your custom content (TRS2004) or commit it with CMP (TRS2006). All within the ability of the average route builder who knows his way round files and the PC but not necessarily have any programming or scripting knowledge.

[AndiS]

Re. initially blue terrain: I guess this can be fixed by adding your developer assets in RBlueprintSetPreLoad before you start the World Editor for the first time, as described here.

Re. developers needing to hack: If Adam does not unveil a great hidden feature which creates your custom textures.bin based on what is in a certain folder, someone else will write this bit of software. It would be great if RSDL would officially unveil the magic behind the various random IDs, to make sure that alternative tools do it right. Not knowing this will not prevent any tool from being written, but there is a (most likely small) chance to run into problems because of misunderstandings. In my own experiments, when I cloned children (to have loads on wagons, e.g.), I did not touch the d:id attribute, so the siblings had the same ID which is the worst case normally, but I did not observe adverse effects, which again does not mean that there are none. On the other hand, we know that d:alt_encoding is ignored, so maybe d:id is ignored, too? As I said, info from RSDL could help prevent corrupted data.

[bigvern]

Exactly my point Andi. You've already lost me me with the tech speak in your last paragraph!

[AndiS]

Sorry for the tech speak. The summary for the non-programmers is this: Kuju put a lot of mystic numbers and codes into the XML files. They look important, but in some cases, they do not seem to be used at all. It is crucial for programmers to find out about them to make sure that external unitility programmes do no harm. RSDL did not help here until now.

<start of moderate tech speak for those interested in details>

Example for useless numbers: Where you specify values like wheel diameter, you find something like d:alt_encoding="XXX" next to the clearly legible value, like 1.23000. The XXX is a complicated representation of the 1.23, and it is proven that it is ignored. So there is no reason for a programmer to worry about it.

Example for an important code: There alpha-numeric strings which for directory names for your own routes, e.g.. Such codes are also used to create references between tracks.bin and the various files in the "Track Tiles" directory, and for scenario referencing. Matt posted a long time ago that creating them is done with some standard method. He did not give details and I have no interest in numerics and code generation, so I cannot advise anyone how to generate them.

Example for numbers with uncertain status: Lots of elements have an attibute named d:id with integer values higher than 100,000,000. Some seem to be referenced within the file, many not. In a small number of experiments, I created several elements in a file with the same numbers. This should be a bad thing, but nothing happened, which can either mean that my experiments were insufficient, or that these numbers are useless.

[t1metraveller]

In my testing, the route and scenario GUID numbers (like 76b3a3f0-c9b0-48f2-9eff-1af9b00166d6 and 00000004-0000-0000-0000-000000000000, etc.) can be made basically random through simple software. I am generating them randomly in my KRS Route Analyzer when cloning routes and scenarios. The ID numbers, between 100,000,000 - 999,999,999 also seem to work well when randomly generated, and I'm using this method as well in the same program. ID numbers seem to always be divisable by 8, however I've had no negative effects when they are not. I think basically if you try to keep numbers from duplicating, things will be all right. However, even this doesn't seem to be a problem when cloning routes, as when the scenarios are cloned I maintain the same scenario folder names for the cloned route without problem. This was also used in the manual route clone method. Randomly generated, the chances of duplicating a number are about the same as winning the lottery with the limits involved.

Was hoping to hear from Adam today on RDSL's thoughts on this texture thing. We must be reading each other's minds, AndiS. Today I've been thinking about a program which will create a texturing.bin file from a list of textures and/or texture sets. I may do some preliminary coding if I get time, to see what comes out of it. It would be nice to have some details on the file format of the .bins in the \MixMap folder. It would make it possible to determine what exact textures have been used in a route, and automate the process of texture selection.

Bill