I've noticed that some of the font symbols affect the vertical justification of text. Certain symbols (such as most of the circular ones in page 6 of the selector, but excluding the fully-filled circle), when placed inline with text, move the entire line of text downward about 15-20% of a line break when used with the new projector devices. I am really having fun with the current implementation of projectors though, and the power of what they will allow us to do is awesome. This is a fully functional heads-up display and control readout system which I've been working on for the past couple of days:
Apologies in advance since this I'm sure someone has already asked this. Will it possible in the future to display pictures on the LCDs? The stats hooks are far more important, no question. I've played a couple games where you simply sized a .jpg (or bmp or pna) correctly, put it in the right directory and it would show in the panels gui. Also played games where it was a real chore to do this, so they were seldom used. Here's hoping, if it gets implemented, that it's fairly straight forward to add custom decorative pictures.
wow smiley were just fun this is way better ..and more than 65 sprites very cool example code <size=55 align="center"><sprite=65> </size> thank you @EleonGameStudios
The .2643 update changed text justification/offset pretty markedly... Does that mean that the size slider and size tags have been rationalized?
I would like to see place-able cameras that can display on lcd screens before anything else. Let us do security cameras and view screens.
We already have better than that : sentry guns, which can be accessed from anywhere. We can tie them to sensors to get an alert on LCDs when someone gets in their range.
Likely a silly question but is there a way to rotate the projection? Say the only place for a projector is on the North wall but you want the display on the West wall...
What a shame. Well i can see why. Except for inappropriate pictures being everywhere, it certainly has an impact on data volume and data traffic. Maybe both could be handled by allowing the upload (custom file directory) only for server admins, and also use could be handled by granting rights to everybody / admin only.
That's an idea... In fact there could be an "official index" for all game textures, that players can replace with whatever they want (with respect to original dimensions), and only index is used to determine what texture goes where. So if a player has custom texture on some blocks, server doesn't have to "read" the texture file but only the index number, for everyone else to have the proper "official" texture assigned. And textures/ images packages could be shared between players who want to have the same experience, but having different textures/ images locally would not impact anything, just visible locally. I guess... ------------------------------- As a side note, some textures could be reduced (if they are not already) to free some channels, if that is the problem. On the 2nd page of the texture tool : The textures I highlighted in red could be much smaller - but like I said it may be already the case, I have no way to know - but they could be just 1/4 their size, or even smaller as they are already "tiles" of a same pattern. In other words, instead of repeating the same pattern on a tile, just use the smallest part as a whole texture, since the engine tiles them anyway. Some textures could be thin rectangles (4th, 2nd row/ 6th, 4th row) but I don't know either if they have to be square. But I'm getting off topic here... I know some games make extensive use of "skins" in the way of joining many textures together as one big multi-textures, and a "window" (the "mapping" method) only shows the relevant part of the big texture, so it becomes a set of coordinates in the "big picture" instead of different pictures.
Alright I might be sticking my neck out here. Unless things have changed drastically. The engine doesn't tile the objects. The mapping is part of the object. Meaning if you made the texture smaller so it was no longer tiled then you must change the mapping on the object to do it. So what happens to the other textures your not wanting to make smaller they become tiled when applied. The object doesn't care what texture is applied the object is just using a selection from the material library. From looking at the objects and avatars I'm sure they are already using skins. This is a more complex way of mapping any object and more time consuming. The modeler has to select just some polys and then map those. He can us different types of mapping techniques to do this. he can rotate the mapping. Then pick another set of polys and repeat. So the over all object can use many different parts of a single texture. Again this is very time consuming. That's why avatar makers are in high demand. But again remember it's all done in the object. The engine doesn't do this. Although you could use different shaped texture sizes. The tools used to make models and avatars prefer to use equal size in even number. In other words squares
Not the objects : the textures. Voxel cubes are generated procedurally here, they are not made in a 3d program then imported into Unity. Mapping here is most probably automated and scripted, like explained/ demonstrated here: https://answers.unity.com/questions/294165/apply-uv-coordinates-to-unity-cube-by-script.html One example of "tiling" is the terrain, and the effect is lessened probably with texture blends/ scaling etc. But get up in the air and you will see the grass base texture "tiles". I don't know what solution/ module is used in Empyrion, but applying alternate mapping methods is far from impossible. Many cool packages for voxel systems come out every year by the way, so solutions may already exist somewhere. That's not what I'm talking about, forgive me for using the "skin" expression. In Unity, these would be "texture arrays" or "tilesheets" (for 2d) or "texture atlas". In Empyrion players are not asking to texture the models and entities, but the "voxel" geometry that make the ships. The point (usually) is to avoid wasting bandwith with multiple image header requests, replacing them with sets of coordinates or indexes for one image (where to look at in the bigger image). This works in a similar way as for "skins" but made programmatically, not by hand - lighter on network usage. It might look insignificant written in text, but think how many times per second all images mapped on blocks are referenced to in code and sent through the network. As I mentioned previously, I have no idea how things work internally in Empyrion. But I do know that "mapping" is modified during the game, as per the "rotate texture" function of the Paint & Texture gun. And it's a cool logic that only takes repetition of the player input to operate. Eleon most probably tried to keep network usage to a minimum, but the nature of the game is their worst enemy here : huge flying grids containing tens or hundreds of thousands of blocks, voxel terrains, lights everywhere... And Unity is regularly criticized for its poor netwrok performance. That's reason enough to always keep performance in mind when asking for features. And Eleon most probably already uses many kinds of index systems for textures, entities and blocks to avoid references bloat over the network.
Al little history here. Using text filed for objects, mesh's and mapping is nothing new. It's been around for ages now. Code: ModelBegin ClumpBegin #Layer: Plane scale 2 2 2 collision off LightSampling vertex Surface 1 1 1 Color 1 1 1 TextureMode lit Texture rw_shrub3 mask rw_mask1 #texbegin Plane Vertex -0.05 0.090631 0.042262 UV 1.0 0 #1 Vertex -0.05 0 0 UV 0 1.0 #2 Vertex -0.05 0 0 UV 1.0 1.0 #3 Vertex -0.05 0.090631 -0.042262 UV 0 0 #4 Vertex -0.042262 0.090631 -0.05 UV 1.0 0 #5 Vertex -0.042262 0.090631 0.05 UV 0 0 #6 Vertex 0 0 -0.05 UV 1.0 1.0 #7 Vertex 0 0 0.05 UV 1.0 1.0 #8 Vertex 0 0 0.05 UV 0 1.0 #9 Vertex 0 0 -0.05 UV 0 1.0 #10 Vertex 0.042262 0.090631 0.05 UV 1.0 0 #11 Vertex 0.042262 0.090631 -0.05 UV 0 0 #12 Vertex 0.05 0.090631 0.042262 UV 0 0 #13 Vertex 0.05 0 0 UV 0 1.0 #14 Vertex 0.05 0 0 UV 1.0 1.0 #15 Vertex 0.05 0.090631 -0.042262 UV 1.0 0 #16 #texend Plane Quad 5 6 9 7 Quad 6 5 7 9 Quad 1 13 14 3 Quad 13 1 3 14 Quad 11 12 10 8 Quad 12 11 8 10 Quad 16 4 2 15 Quad 4 16 15 2 ClumpEnd ModelEnd Now this is a simple shrub I had created. The format is called rwx and it's still used today in some 3d multi user worlds. It is text based I has a texture and and mask for the leafs can be looked through. This is only one large leaf that I would duplicate in a circle to be used in a forest. It has collision off so you can walk through it. theUV Definition is the UV number in the Vertex line. UV Mapping is the Quads in the lower part of the file. Sure this can be automated. Even in the explanation you show with the url. They called the mesh that will be used in this case a simple primitive cube and then apply the UV the rwx format allows for the same thing to be done. My point is the mapping still has to be done to the object it self. Sure could automate changing UV mapping on the fly. The problem with Text base objects and mapping is it's slow. It still has to go through an interpreter to be rendered I agree they might be doing it differently but the concept is not new. rwx has been around for over 20 years now.
Ok I have done a little bit of searching to get a better idea of how mapping and voxels work. Now from what I can tell they most likely use blender to create the object even the cube and then map the object and a texture for all six sides then map the object so each face of the cube is mapped to some part of the texture. They may also have a blank line between the 6 textures to stop bleed. Next they would export this object with it's uv mapping. This export would be an .obj file which is a text based object format which was created by Wavefront in 1988. So it might give you an idea how long these things have been around. (This was my edit) This would be their base model. Then in unity them would be able to change the texture on the object to what they want. Now at this point is when untiy takes over and the textures are done of the fly so are the uv's but this is for the rendering part as you move around. It is still using the base uv's that were applied to the object or mesh when it was created. It's what your seeing that is done on the fly. when you rotate a texture your not rotating the UV but the copy of the texture that was applied. Now I'm not untiy or voxels master I wish I was 10 years younger and was still doing this as a living. Unity is an amazing peace of work from what I have read. It's scripting language is really easy to understand. But all in all it's having to use many of the basic concepts of model making. The Voxels system is also amazing and takes your work renders only the part you need to see on the fly cutting down on the use of triangles . As I said I'm only guessing here from the amount I have read on the tech sites for voxel and untiy. Sure they could do a number of things but there is a trade off. Larger textures more rendering time and lag. Larger meshs again more rendering time and lag. They would be playing a constant battle to keep things as small as possible and yet give the illusion it isn't small. As I said this is all a guess and I have no idea how they are doing things in house but it would be a fun house to be part of!
Well I'm only guessing too, as I have no clue what combination of packages/ scripts/ compiled code is at play here. https://docs.unity3d.com/ScriptReference/TextureWrapMode.html From the Unity manual : "When UVs are outside of the 0...1 range, the integer part will be ignored, thus creating a repeating pattern". So if set as default behavior, "square" textures will simply wrap once, and smaller textures will "tile". Does this make sense ? It was pretty standard in other game editors that allowed thin, non-square textures (default to tile). I would be surprised that a more modern game engine would not allow it. In other words, there's not even need to change mapping here, just choose "tile" as default. This would allow for many very small textures (the ones I highlighted up here). Then if you read about the "texture arrays" or "atlas" it's just a question of reference to coordinates to get the tiny texture to tile.
Yes this makes sense think of it this way. A texture is 100 * 100 pixils a 1 to 1 map would mean the texture would be 100 across and down if applied to a flat panel. Now if the map is .25 to 1 then the mapping would start at the 25th pixel and when it reached the 100's then it would go back to the 1st pixel and continue on. still applying the whole 100. Now if the map was .25 to .75 then it would apply the 25th pixel to the 75th pixel stretching the texture across the panel. Same would be for the sides. that's in the simplest form. So by using a combination of texture size and mapping you could get a single texture to be used for the whole object. But there are many mapping techniques you can use. In the early days we had to do this all by hand and make and apply the mapping numbers. Bring it into a render and see what the outcome was. But once the tools started coming out where we could make our 3d objects in a program and see the outcome right away things got a whole lot easier. The last 3d program I used was Max 3d or was it 3d Max lol
Exactly. That's why I made a reference to skins, as they are mostly the same principle as texture arrays. In the textures I highlighted up here there are repeating patterns that could be put in a single file: >>>>>> And even here I took too much of #2 and #4 : they could be only 1 little square. So 64 of these "patterns" could be stored in a single file/ array, and only referenced by coordinates (position in the array). I suspect that some part of the latency on servers is due to the server waiting for client responses, as the game also struggles locally even on good machines. Anything that could ease local render could help. That is an highly uneducated guess. I have no clue what the memory usage of textures is, but I know that some players mention the game forces half-textures when ram is insufficient. That may be caused by many things so just poking in the dark here...
Ok first problem by having different size textures as you are showing there. Your asking for two different uv mapping. There is a reason why all the textures are the same size. This way they can use one size block to fit all textures. Now your asking them to make 3 different blocks with different mapping to accommodate the 3 different size textures. So one base block to handle the normal size texture. 2nd one for the two smaller square textures so the object can tile them both directions and then a 3rd base block to handle the two rectangle textures now you have tripled the number of the objects. Remember they still have to use a base object. That's not even counting all the different shapes they have besides a square cube. Now you have also increased the load on the system because your no longer using just one object. At least that is how I would see it working. edit to fix spelling
