Experimental v1.3

F=ma, so Acceleration is force divided by mass. We can't reach light speed because special relativity shows that mass increases with velocity. However it is not linear, and this effect is negligible at anything less than absurd velocities. For example relativistic mass at half the speed of light is still only an extra 15%. At 100 meters per second special relativity is not a factor and has nothing to do with the speed limits in Empyrion.

 

In Empyrion we can go faster than light, but I guess you already noticed that...

I knew someone would give me the "realistic" explanation, I just didn't expect it would be you.

 

What about this error that floods the logs over and over and over...

Warning/GameAnalytics: Event queue: Failed to send events to collector - Retrying next time
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

 

Similar to THIS ->


It produces in the Logs ->

857,55 | DType = | Fac = [??? -1] | TUId = 66
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

 

I have this error in the current public version.. AND the experimental version that I'm running.. as do several of my friends.

It appeared a couple of updates ago. I've completely uninstalled.. and re-installed... to no avail.

 

There ya go!

 

Wait so the decals just float and are not part of the block's actual texture? I had the impression that these decals would basically just be more textures that would be applied to a block through the texture/color tool in creative.

 

They are independant from blocks, but we can place them very tightly against blocks, and we can even replace blocks with them since they can have collision (but no damage).

Here's an example of a small decal placed very close to a block :





This is a 256 x 256 pixels png image, scaled at 1 x 1, which fits one BA/CV block size precisely. Positioning can be done with decimal (floating point) values and the example here is at 0.001 unit (1/1000 th of a block's thickness) from the surface. One block = 2m, so this decal is at 2 mm from the block's face.




But apart from sticking them to blocks, decals can be whatever we can think of that requires planes...





I saw in today's patch notes that we now have a "control block" to act as switch to disable decals per name in game. I have to check how this works, as it opens yet lots of possibilities.

.

 

Is there a limit to how many decals can be placed on a structure? Also can they not be added beyond the 250x250x250 block limit boundary on structures?

 

I don't know if there is a technical limit, but I have added 14 mp4 decals to a structure without issue.
I've also placed 900x900 sized decals fairly far from a structure.

They can be whatever size you want, though there's no guarantee your computer can handle it.

 

It's a block that can be accessed in the control panel and you can either manually turn it on or off, or use signal logic to control it.
There's a text entry field you can add the name of the decals to control. I don't know if multiple names can be added, but you can name all the decals the same so a single control block can control multiple decals.

It looks like a steel block. Has no shape options but can be textured.

 

Yes, they can be placed far from a structure, as I showed on another thread ( post #22905) :

https://empyriononline.com/threads/what-did-you-do-in-empyrion-today.2826/page-1146

The amount of decals and impact on performance follows the same rules as all geometry / texturing in the game. There are huge advantages to use decals compared to blocks in certain circumstances, as one big decal can cover an area of thousands of blocks, and they are only 1 plane with a texture scaled on it. Actually it's the image on the decal that takes most resources, and we can follow simple rules like what is done in classic 3d design software to avoid problems. Pure transparency = no pixel to render ( "cutout" option in the decals settings), so the renderer doesn't count all these. Scaling of a small image takes less video memory compared to loading one big, detailed image. Powers of 2 images (256 x 512, 128 x 128, etc) are usually "easier" on rendering and have been used extensively in game design :

https://software.intel.com/content/...-of-two-textures-have-better-performance.html

Now that's a funny bit, as many of the terrain "stamps" don't follow that rule, and have strange dimensions when thinking of storage and performance.

Like @ravien_ff mentioned we can also use mp4 videos, and this means that we can make short animations to be displayed with decals, like animating a "forcefield" effect with transparency, or a thin layer of fog on the ground, etc. No need to have more that 1 to 3 seconds of animation for such small effects, and since they can overlap (with "fade" parameter) we can use very short clips.

The semi-transparent effects for decals ( "transparent" and "fade" ) may be the most demanding, like fog in the game, because they require the renderer to calculate front and behind pixels and light going through the 1st layer, etc. Best to keep these for closed indoor areas, or empty space. We can use bumpmaps too, but these give mixed results depending on size and player proximity to the texture, so sometimes they just waste performance when another method could have been used.

@Hummel-o-War : one option that could be added (besides making the decals airtight true/ false) would be tiling ( with amount x, y ), to be able to use a small image on a wide surface and repeating the small image instead of stretching it, which makes big pixels apparent and not nice.

I guess that asking for simple "triangles" would be too much, but hey... why not !?
.

 

This is important to highlight. Decals are indeed a huge performance boost if used properly. One of the main motivation for decals were the replacement of LCDs. Many don't know HOW expensive such LCDs are, I think.

Or simply put: Compare the amount of Triangle here (LCD):


With a Decal:


Hard to see but a Decals contains of 2 triangles.
An LCD Screen contains 2 multiplied by characters triangles. Example above = 35 Triangles.

The only untested questions are: what are limits regarding dimensions and VRAM.
The size of the decals doesn't matter. The dimension of the source file is what makes it problematic.
A 512x512 .jpg scaled ingame to 256x256 is way better than a 2048x2048 .jpg scaled ingame to 64x64 for example.
Cause they are rendered on the GPU and kept in the Cache/Memory.

A lot of tests are still to be made with all of the new stuff, especially in Multiplayer but just a little information.

 

That is why I asked to add an option to "tile" the image, as we can also replace other geometry, but it will look bad if the image/ texture is stretched many times. By tiling the image we can use pictures of blocks or even make images from screenshots to have the precise color and pattern, then use this as a tiled texture on the decals. This way instead of making a 16 x 512 image to simulate a long pipe with many joints, we can use a 16 x 32 image with one joint at each end, stretch it to 256 in the decals.txt file and tile (repeat) the image 16 times on the X or Y axis, for example.

Since these will be used in POIs and might be indestructible, we can make large environment/ structures rapidly without using thousand of blocks for simple flat surfaces, or use much smaller images stretched and repeated to get better visual with less impact on performance. Basically, to replace thousands (or millions) of pixels in video ram by hundreds/ few thousands and one or two operations (stretch + tile).

 

Ok. I checked it and like you described, we can simply name multiple decals with the same identifier to activate/ deactivate them as a group.

Spoiler: Meaning that...

I have 4 pictures named Decal001.png to Decaloo4.png. In the settings file I will name them as Decal1, Decal2, Decal3 and Decal4. But if I want image 2 and 3 to be triggered I can name them both Decal2, and use that name in the control block's name field.

All decals active :



So we use the names in the settings file, not the name of the images :

[Decal1]
-Mode=Opaque
-Pos=0,132,0
-Rot=0,0,0
-Size=1,1,1
-Cull=false
-ColliderMode=Collision
-Diffuse=Decal001.png

[Decal2] << name to be used in the control block's text field
-Mode=Opaque
-Pos=0,132,0
-Rot=0,0,0
-Size=1,1,1
-Cull=false
-ColliderMode=Collision
-Diffuse=Decal002.png << name of the image file

[Decal2] << name to be used in the control block's text field
-Mode=Opaque
-Pos=2,132,0
-Rot=0,0,0
-Size=1,1,1
-Cull=false
-ColliderMode=Collision
-Diffuse=Decal003.png

[Decal4]
-Mode=Opaque
-Pos=3,132,0
-Rot=0,0,0
-Size=1,1,1
-Cull=false
-ColliderMode=Collision
-Diffuse=Decal004.png




When the signal is closed, both decals with the name Decal2 will be turned off :



The decal is gone and the space is empty, meaning that when the decals has collision, collision is gone when the decal is disabled.

This is cooooool . ^^

 

Excuse my simple minding thinking. So in a case like this, it could be used for say - a trap door/floor, and it would save on geometry by not needing an animated block. Or even a barrier that can not be crossed until the signal is activated?
This is all sounding very interesting but also very complicated to the less experienced.