Visual problems

[mindrage]

Some problems:

• Z Issue with Zones and borders - BorderItems overlap zones, making them standout.
• "Player view" - The roof above the center of the camera dissappears as if it was ingame, This should be an camera option in camera settings or something.
• The transparency of roofs/caves should be available as option at a toolbar.
• Large map view is a bit strange,You move, and it resets the map for each step you take. I dont know if its a RenderToTexture approach or a gradual vertex loading There has to be a faster way to render it. that could include multiple floors. I'll try to see if i can find any solution

[edubart]

• Large map view is a bit strange

To render the entire map with zoom out is a heavy task, because of this when there is too much tiles to render the otclient's MapView prefer to render maximum of 7_128_128 = 114688 tiles per frame, and schedule the remaining tiles to be drawn to the next frame, instead of freezing your screen. There is no way to render so many tiles faster. If you want to see the map with high zoom out use the minimap.

[asamy]

• "Player view" - The roof above the center of the camera dissappears as if it was ingame, This should be an camera option in camera settings or something.

This is fixed, it's now optional whether to show the upper floor or not.

• The transparency of roofs/caves should be available as option at a toolbar.
• Z Issue with Zones and borders - BorderItems overlap zones, making them standout.

I don't get what do you mean by those.

[mindrage]

Lets say an approach of rendering a chunk of the map to a texture, if we went with 32x32 per chunk. At a normal zoom a 32x32 chuck would takes 32 * (32 + 1) = 1056x1056 pixels to render to a texture, so lets say 31x31 chucks to make the size 1024x1024 textures at normal zoom. to save a 1024x1024 texture with RGBA 32 bit, it would take 4 MB per texture in the RAM, Thats ofc way to large, but lets assume the zoom with mipmap. A zoom where 1 tile takes 8 pixels wide would give a reduction by 8 * (32) = 256x256*4 bytes per texture. So if a screen was at 8 pixels per tile, a screen with 1280x720 would be 160x90 tiles, aka 5 x 4 x 7 floors. 140 chucks, with 256x256x4 bytes stored. aka 36 MB for the entire screen. 1 chuck would render 1 floor and you would only need 280 triangles to render it.

So the fact is you can have a background proccess that generates the chuck texture at 8 pixels per tile, let it mipmap it, then simply update the textures on edit after x amount of seconds. The only drawback with this is that you would have to Cache the stored textures, it would take space on the HDD, but im sure there is already good compressions.

but the good things are, You wont have the GPU massively working when not editing, when editing, you can wait a time without map updates until generating new texture. You can have multiple floors rendering simultainously with able to filter the top ones out. And you can have the entire map rendered with (31*31) times less vertexes each frame.

As for this thing, its is only for the large map view ofc.

So to sum up. render a mipmapped of a 31x31 piece of the map to a smaller texture, 256x256 for 8 pixel/tile zoom, 128x128 for 4 pixel/tile zoom, 64x64 for 2 pixel/tile zoom, 32x32 pixels for 1pixel/tile zoom, Save the textures cached, Update when the map is edited and wait 5 seconds before cache, or force cache if zoom appears.

Its only a suggestion ofc.

[mindrage]

• The transparency of roofs/caves should be available as option at a toolbar.
• Z Issue with Zones and borders - BorderItems overlap zones, making them standout.

Here you see that the roofs are transparent with a Protection zone, You can barely see the tiles. Also the Borders of the water/rad and building is not colored as the zones is, which makes them appear as if they were on another floor or something

This is using the beta release. not using the latest developer verision.

[asamy]

Can you change the following:

g_map.setZoneOpacity(0.5)

To like:

g_map.setZoneOpacity(0.3)

Try with more values and see which one is better. This can be found in modules/mapeditor_interface/interface.lua

[edubart]

@mindrage I had spent weeks toughting about that already, that way is indeed a good approach for reaching maximum zoom out view with realtime rendering, what you said is basically a widely technique used by many algorithms called dynamic programming (cache every work you do, reuse them to avoid recalculation, thus reaching optimal performance, with the only cost of memory).

However otclient's MapView was always intended and designed to work for playing the game, thus it has to support lights, animations, floor view changes and movement. That idea is not possible to work with all those features, this mean that we would have to split the rendering code, and maintain two classes and algorithms, one for close view and that one for far view, otclient kinda do something like by switching rendering strategegy depending of the zoom factor but I did not went that far. What I did in the MapView was the best to work in both worlds using the same code. None of us will put effort creating a new algorithm for that wish of having realtime zoomout rendering, as you can already view everything with zoomout, you just have to wait the draw completion.

[mindrage]

@edubart Well, The rendering is really great so far, but the fact that when you move the position, the entire thing resets, Isnt it possible to just keep rendering it out even if you move it? Like translate the vertexes of texture a bit? Or is it the fact that you dont render to any texture and just render it directly?

@decltype I tried to change the zone opacity to 0.3, but after some testing i would suggest 0.7 to 0.8 as you then can see the actual floor.

[asamy]

@mindrage It's a mapeditor fault, that will be fixed soon. About the zone opacity, it can be changed

[edubart]

@mindrage Otclient do render everything onto a texture, but the texture is only large enough to hold that visible area that you have sigh, and everytime you move the camera that texture must be cleared and everything redrawn. The pixel area that you don't have sight anymore will be lost in favor to free space for drawing the new visible area. There is no way to just translate the vertexes, all vertexes will be recalculated, old vertices are lost, and new vertices come in place, while all of them have to respect a specific order. Also there is no such thing as a huge vertex array to just translate, each item being drawn has its own vertex array because OpenGL can't switch texture states inside a single draw call.

[mindrage]

@edubart so a deffered rendering approach?, im sure you could do the same approach you do now, but render into fixed sized textures and just keep those textures visible on screen. If a proper size would be 512x512, a 1024x768 would have 3x3 texures at max. approaching 9 mb memory cost. full HD would be 5x5 approximating 25mb memory cost. Checking if a section is out of bounds should be alot cheaper than reseting the drawing order all the time.

[edubart]

@mindrage That would take a lot of work, as I said we are not putting effort to create a new algorithm for that wish of having realtime zoomout rendering. On the other side otclient's minimap do work that way, each minimap chunk is a block of 64x64 tiles rendered into textures, use the minimap for really deep zoom out.

[comedinha]

Same error

[mindrage]

@BrunoDCC for a temporary solution, as they are fixing it, open terminal and write g_map.setZoneOpacity(1.0) and it wont be transparent at all

[comedinha]

work :+1:

[asamy]

I see no point having this open.