OHM Generic Billboard

[OrbitHangar]

Author: wehaveaproblem

Basic billboard taken from ORL add-on, for use by anyone in their own bases.

There is no documentation included, just the mesh and default texture, so some knowledge of meshes and textures will be required to use and adapt to your own needs/advertisments.

DOWNLOAD

 

[Carmen A]

Awesome - it's simple addons like these that make bases really feel at home :3

It's a great way to start off modding too. Small stuff don't bite back. (Unless of course, billboard collapses on you).

If you put many of these objects in game you will end up with generic billboard spam. However, you can create copies of the mesh files, open the MSH with notepad and change the texture at the bottom!

Just don't forget to credit WHAP if you use this "product", which is also featured in ORL (Orbiter Racing League) at his Ascension Island Base :3

 

[fsci123]

Is there any starter example code for how to put this in our bases?

 

[garyw]

Add it to the bases config file as MESH block. I don't have orbiter in front of me so can't give you a sample but if you open up the KSC.CFG file you should see how to do it.

The other option is to give the mesh a CFG file under config\vessels then use scenario editor to place it.

 

[wehaveaproblem]

Ok, some quick instructions:

Find the appropriate base config file. e.g. Config/Earth/Base/mybase.cfg

then add this to the BEGIN OBJECT LIST section

MESH
    FILE Billboards/Billboard
    POS 0.0 0.0 0.0
    SCALE 1 1 1
    ROT 0
PRELOAD
UNDERSHADOWS
OWNMATERIAL
END

You can add as many as you want, wherever you want, but they will all have the same advert texture. So...

If you want to use ONE different texture, simply replace the default one with another of the same name.

or if you want multiple textures...
Edit the Billboard.msh file. At the end, change this:

TEXTURES 2
Billboards/concretetex.dds
Billboards/default_bill.dds

To this:

TEXTURES 2
Billboards/concretetex.dds
Billboards/my_texture_name.dds

Then copy the mesh file and rename it billboard1, billboard2 etc. Change the texture name for each one individually. Then load them individually in the base config file.

All textures should then go in Textures/Billboards/

Hope that all make sense.

 

[Stevodoran]

Ok, some quick instructions:

Find the appropriate base config file. e.g. Config/Earth/Base/mybase.cfg

then add this to the BEGIN OBJECT LIST section

MESH
    FILE Billboards/Billboard
    POS 0.0 0.0 0.0
    SCALE 1 1 1
    ROT 0
PRELOAD
UNDERSHADOWS
OWNMATERIAL
END

You can add as many as you want, wherever you want, but they will all have the same advert texture. So...

If you want to use ONE different texture, simply replace the default one with another of the same name.

or if you want multiple textures...
Edit the Billboard.msh file. At the end, change this:

TEXTURES 2
Billboards/concretetex.dds
Billboards/default_bill.dds

To this:

TEXTURES 2
Billboards/concretetex.dds
Billboards/my_texture_name.dds

Then copy the mesh file and rename it billboard1, billboard2 etc. Change the texture name for each one individually. Then load them individually in the base config file.

All textures should then go in Textures/Billboards/

Hope that all make sense.

Ill be sure to add plenty of these.

 

[paddy2]

This will be a great way of giving credit to the many of you out there who have provided addons and help. On my base I intend to use them outside office "Blocks" to name a make believe company Dans insurance, csanders metal works. That sort of thing!

 

[martins]

Then copy the mesh file and rename it billboard1, billboard2 etc. Change the texture name for each one individually. Then load them individually in the base config file.

Wouldn't it be better to replace the OWNMATERIAL tag with the TEX tag in the base config file to provide support for multiple textures, without the need for replicating the mesh file? Or is there a particular reason you want to have the OWNMATERIAL tag?

Also if you have many billboards using the same texture, it may be worth considering using the "BLOCK" object type to define a billboard rather than a custom "MESH" object. A BLOCK may have a few redundant surfaces (it defines 5 sides rather than 2), but the advantage is that Orbiter automatically merges all predefined object types with the same material and texture into a single mesh, and renders them all with a single call, rather than rendering each 8-vertex mesh as a separate object. This may or may not have an effect on rendering efficiency. Why don't you simply create a base with 10000 billboards using each of the two methods, and check if there is a framerate difference.

Edit: Looking closer at the billboard image, it seems that the mesh is a bit more elaborate anyway than just a 2-sided rectangle, so using a BLOCK object wouldn't incur any additional penalty. If you want, you could even simulate the two posts with texture transparency.

 

[wehaveaproblem]

Bit of a thread res here, so apologies, but only just saw martins very useful reply. Thanks Dr, I had never considered that!

Although I would say that with the transparency option you may find some visual artefacts occur, as had been demonstrated well in the AU dev thread, but probably nothing that would hinder one's experience.

Martins, if you happen to see this reply, could you throw a little wisdom on how much extra CPU usage there would be with the transparency option, if any? I ask because I was going to use transparency for the trees I want to add to AU and was curious if it would add much load? Since the windows at AU do seem to.

Cheers

 

[martins]

Martins, if you happen to see this reply, could you throw a little wisdom on how much extra CPU usage there would be with the transparency option, if any? I ask because I was going to use transparency for the trees I want to add to AU and was curious if it would add much load? Since the windows at AU do seem to.

They do? Interesting ...
Transparency shouldn't add any load on the CPU, and not a lot on the GPU. The only difference is that the renderer has to combine the pixel colour information of the (semi-)transparent surface with that of the background, rather than just replacing it. But graphics cards are good at this type of operation, so I am surprised that there should be a noticeable performance difference.

The real problem with transparency is that z-buffering doesn't work well with it. A rendered surface always writes to the z-buffer and thus hides everything behind it. The z-buffer doesn't distinguish between opaque and transparent surfaces. So you need to make sure that everything behind the transparent surface is rendered before that surface, otherwise it won't show. In practice that means depth-sorting objects and rendering them from back to front (painter's algorithm). At the moment orbiter doesn't really provide a mechanism to do that for base objects.

 

[wehaveaproblem]

They do? Interesting ...
Transparency shouldn't add any load on the CPU, and not a lot on the GPU. The only difference is that the renderer has to combine the pixel colour information of the (semi-)transparent surface with that of the background, rather than just replacing it. But graphics cards are good at this type of operation, so I am surprised that there should be a noticeable performance difference.

The real problem with transparency is that z-buffering doesn't work well with it. A rendered surface always writes to the z-buffer and thus hides everything behind it. The z-buffer doesn't distinguish between opaque and transparent surfaces. So you need to make sure that everything behind the transparent surface is rendered before that surface, otherwise it won't show. In practice that means depth-sorting objects and rendering them from back to front (painter's algorithm). At the moment orbiter doesn't really provide a mechanism to do that for base objects.

Thanks for the prompt reply. First, I may be using the term gpu load incorrectly, I did just mean general FPS performance. Plus, I did also make some other texture and mesh refinements along with the window reduction, so perhaps my observations are misguided.

And yes, unfortunately AU dev has made myself and face very aware of the z buffer issue! Which is what I was referring to when I spoke of visual artefacts. We have ended up separating out the windows from the buildings and loading them separately after all other meshes as an attempted workaround for this, although it is still work in progress, and doesn't solve the issue when vessels are added to the scn file and therefore loaded after the base.

But it's good to know I can be window and transparency generous without worry to fps, so thank you.