Optimize SVG images and convert most PNG images to WebP
Aaron Franke
1
.gitignore
vendored
@ -6,3 +6,4 @@
|
||||
*.obj
|
||||
*.pyc
|
||||
*.tmp
|
||||
.DS_Store
|
||||
|
||||
@ -18,7 +18,7 @@ The mesher has a `library` property of type `VoxelBlockyLibrary`. This is a reso
|
||||
First, set how many voxel types you need by setting the `voxel_count` property. If you need more later, you can increase it.
|
||||
A list of voxel types is shown below:
|
||||
|
||||
|
||||
|
||||
|
||||
Each slot can contain a `VoxelBlockyModel` resource. The index shown on their left will be the ID they use in voxel data. Voxel `0` is a special case: by convention, it may be used as the default "air" voxel. You may assign a new `VoxelBlockyModel` resource to each slot, and fill in their properties.
|
||||
|
||||
@ -30,25 +30,25 @@ A simple start is to set the `geometry_type` to `Cube`, so the voxel will be a c
|
||||
|
||||
With this mesher, using atlases is recommended to allow re-using materials and reduce the number of draw calls. You can create a texture containing all the tiles your voxels can use. For example, here is one from the [blocky game](https://github.com/Zylann/voxelgame/tree/master/project/blocky_game) demo:
|
||||
|
||||
|
||||
|
||||
|
||||
This atlas is a square texture and can contain up to 16x16 tiles. This number is important and needs to be set on the `VoxelBlockyLibrary` `atlas_size` property, so texture coordinates can be generated properly when you use the `Cube` geometry type:
|
||||
|
||||
|
||||
|
||||
|
||||
Voxel types using the `Cube` geometry can have different tiles on each of their faces. You can decide which one to use by assigning properties of `Voxel`, under the `Cube tiles` category. Coordinates here are in tiles, not pixels.
|
||||
|
||||
|
||||
|
||||
|
||||
For example, if you want to use the "planks" tile, you may use x=3 and y=1:
|
||||
|
||||
|
||||
|
||||
|
||||
So far we defined a cubic voxel with specific texture coordinates on its faces, but we still have to actually assign the texture and material used to render it. This can be done in the `Material overrides` section, in which you can assign a material with the texture in it.
|
||||
|
||||
Make sure to assign its `albedo_texture` to your texture. You may also check the `Vertex Color/Use as albedo` property, because this will allow the mesher to bake ambient occlusion on the edge of cubes.
|
||||
|
||||
|
||||
|
||||
|
||||
Each model can use different materials with different textures, but keep in mind the more you re-use materials, the better. It reduces the number of draw calls and makes rendering faster.
|
||||
|
||||
@ -56,7 +56,7 @@ Each model can use different materials with different textures, but keep in mind
|
||||
|
||||
Creating voxel types with the `Cube` geometry is a shortcut that can be used for simple voxels, but the most versatile workflow is to use actual meshes. If you change `geometry_type` to `CustomMesh`, you are allowed to assign a mesh resource. In this mode, the `Cube tiles` properties are not available, because you will have to assign texture coordinates of the mesh within a 3D modeler like Blender.
|
||||
|
||||
|
||||
|
||||
|
||||
Meshes can have any shape you want, however there are a few constraints to respect:
|
||||
|
||||
@ -66,7 +66,7 @@ Meshes can have any shape you want, however there are a few constraints to respe
|
||||
- Keep it low-poly. The mesher can deal with large models, but performance can decrease very quickly if a complex model appears a lot of times.
|
||||
- Faces lying on the sides of the 1x1x1 unit cube will be the only faces that can be culled by the mesher. Make sure they are perfectly lining up. If they don't, it can cause dramatic slowdowns due to the amount of generated geometry not getting culled.
|
||||
|
||||
|
||||
|
||||
|
||||
The best format to use to export your meshes is OBJ. Godot imports this format by default as a mesh resource. Other formats are not suitable because Godot imports them as scenes, and `VoxelBlockyModel` resources require meshes, not scenes.
|
||||
You can choose to export materials from here too, but it is recommended to do it in Godot because it allows you to re-use them.
|
||||
@ -101,13 +101,13 @@ Both require to use a different material from the default one you may have used.
|
||||
|
||||
`VoxelBlockyModel` resources also have a `transparency_index` property. This property allows to tune how two voxels occlude their faces. For example, let's say you have two transparent voxels, glass and leaves. By default, if you put them next to each other, the face they share will be culled, allowing you to see through the leaves from the glass block:
|
||||
|
||||
|
||||
|
||||
|
||||
If two faces touch each other, if they have the same transparency index, they can get culled. But if their transparency index is different, they may not. This allows to see the leaves directly behind glass, instead of seeing the insides.
|
||||
|
||||
Here, glass has `transparency_index=2`, and leaves have `transparency_index=1`:
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Random tick
|
||||
|
||||
@ -4,7 +4,7 @@ Editor
|
||||
Previewing in the editor
|
||||
---------------------------
|
||||
|
||||
|
||||
|
||||
|
||||
### Preview options
|
||||
|
||||
@ -14,7 +14,7 @@ If the generator or stream is providing a type of voxel data which is not suppor
|
||||
|
||||
The whole terrain can be told to re-mesh or re-load by using one of the options in the `Terrain` menu:
|
||||
|
||||
|
||||
|
||||
|
||||
!!! warning
|
||||
If you use a script on either [VoxelGeneratorScript](api/VoxelGeneratorScript.md) or [VoxelStreamScript](api/VoxelStreamScript.md), the `run_stream_in_editor` option will automatically turn off and the volume will not be visible. If a script gets modified while it is used by a thread in the editor, unpredictable bugs can happen. You can force it by enabling the option, but you have to make sure no change happens. This limitation is tracked in [issue177](https://github.com/Zylann/godot_voxel/issues/177).
|
||||
@ -24,7 +24,7 @@ The whole terrain can be told to re-mesh or re-load by using one of the options
|
||||
|
||||
Blocks will only load around the node's origin by default. If the volume is very big or uses LOD, it will not load further and concentrate detail at its center. You can override this by going in the `Terrain` menu and enabling `Stream follow camera`. This will make the terrain adapt its level of detail and blocks to be around the editor's camera, and will update as the camera moves. Turning off the option will freeze the terrain.
|
||||
|
||||
|
||||
|
||||
|
||||
This option exists for large volumes because they need to stream blocks in and out as you move around. While this is often done in a controlled manner in a game, in the editor the camera could be moving very fast without any restriction, which can demand much more work for the CPU.
|
||||
You can monitor the amount of ongoing tasks in the bottom panel, while the node is selected.
|
||||
|
||||
@ -29,19 +29,19 @@ The following screenshots use a smooth `VoxelLodTerrain`.
|
||||
|
||||
Generates a flat ground.
|
||||
|
||||
|
||||
|
||||
|
||||
### [Waves](api/VoxelGeneratorWaves.md)
|
||||
|
||||
Generates waves.
|
||||
|
||||
|
||||
|
||||
|
||||
### [Image](api/VoxelGeneratorImage.md)
|
||||
|
||||
Generates a heightmap based on an image, repeated infinitely.
|
||||
|
||||
|
||||
|
||||
|
||||
!!! note
|
||||
With this generator, an `Image` resource is required. By default, Godot imports image files as `StreamTexture`. You may change this in the Import dock. At time of writing, in Godot 3, this requires an editor restart.
|
||||
@ -50,13 +50,13 @@ Generates a heightmap based on an image, repeated infinitely.
|
||||
|
||||
Generates a heightmap based on fractal noise.
|
||||
|
||||
|
||||
|
||||
|
||||
### [Noise (3D)](api/VoxelGeneratorNoise.md)
|
||||
|
||||
Generates a blobby terrain with overhangs using 3D fractal noise. A gradient is applied along height so the volume becomes air when going up, and closes down into matter when going down.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Node-graph generators (VoxelGraphs)
|
||||
@ -86,11 +86,11 @@ The simplest possible graph with a visible output is a flat plane. The SDF of a
|
||||
|
||||
Right-click the background of the graph, choose the nodes `InputY` and `SdfOutput`, then connect them together by dragging their ports together.
|
||||
|
||||
|
||||
|
||||
|
||||
It is possible to decide the height of the plane by subtracting a constant (`sdf = y - height`), so that `sdf == 0` will occur at a higher coordinate. To do this, an extra node must be added:
|
||||
|
||||
|
||||
|
||||
|
||||
By default, the `Add` node does nothing because its `b` port is not connected to anything. It is possible to give a default value to such port. You can set it by clicking on the node and changing it in the inspector.
|
||||
|
||||
@ -106,33 +106,33 @@ There are several types of noise available, each with their own parameters. At t
|
||||
!!! note
|
||||
After you create this node, a new `FastNoiseLite` resource must be created in its parameters. If that resource is not setup, an error will occur and no voxels will be generated.
|
||||
|
||||
|
||||
|
||||
|
||||
3D noise is more expensive to compute, but is interesting because it actually produces overhangs or even small caves. It is possible to replace 2D noise with 3D noise in the previous setup:
|
||||
|
||||
|
||||
|
||||
|
||||
You might notice that despite it being 3D, it still appears to produce a heightmap. That's because the addition of `Y` in the graph is gradually offsetting noise values towards higher and higher values when going towards the sky, which makes the surface fade away quickly. So if we multiply `Y` with a small value, it will increase slower, letting the 3D noise expand more (`sdf = y * height_multiplier - height + noise3d(x, y, z)`):
|
||||
|
||||
|
||||
|
||||
|
||||
#### Planet
|
||||
|
||||
We are not actually forced to keep generating the world like a plane. We can go even crazier, and do planets. A good way to begin a planet is to make a sphere with the `SdfSphere` node:
|
||||
|
||||
|
||||
|
||||
|
||||
We cannot really use 2D noise here, so we can add 3D noise as well:
|
||||
|
||||
|
||||
|
||||
|
||||
However you might still want a heightmap-like result. One way to do this is to feed the 3D noise normalized coordinates, instead of global ones. Picking a ridged fractal can also give an eroded look, although it requires to negate the noise multiplier node to invert its distance field (if we leave it positive it will look puffed instead of eroded).
|
||||
|
||||
|
||||
|
||||
|
||||
!!! note
|
||||
You can obtain a donut-shaped planet if you replace the `SdfSphere` node with a `SdfTorus` node.
|
||||
|
||||
|
||||
|
||||
|
||||
#### Caves
|
||||
@ -142,23 +142,23 @@ However you might still want a heightmap-like result. One way to do this is to f
|
||||
|
||||
It is possible to generate caves by subtracting noise "worms" from a base SDF terrain. To simplify the approach, let's first look at what 2D noise looks like, with a few octaves:
|
||||
|
||||
|
||||
|
||||
|
||||
If we multiply that noise by itself (i.e square it), we obtain this:
|
||||
|
||||
|
||||
|
||||
|
||||
And if we clamp it to highlight values below a threshold close to zero, we can notice a path-like pattern going on:
|
||||
|
||||
|
||||
|
||||
|
||||
In 2D (or in 3D when using normalized coordinates) this is the key to produce rivers, or ravines. But the problem with caves is to obtain 3D, round-shaped "worms", not just 2D shapes. So we can cheat a little, by still using 2D noise, but instead we modulate the threshold along the Y axis. We need a parabola-shaped curve for this, which can be obtained with a second-degree polynome like `y^2 - 1`:
|
||||
|
||||
|
||||
|
||||
|
||||
Back to the voxel graph, we may connect directly the cave generation nodes to the output just to preview what they look like, without the rest of the terrain:
|
||||
|
||||
|
||||
|
||||
|
||||
After tweaking noise and other values, we obtain those famous worms, but there are two problems:
|
||||
|
||||
@ -167,15 +167,15 @@ After tweaking noise and other values, we obtain those famous worms, but there a
|
||||
|
||||
We can fix the first problem by adding an extra layer of 2D noise to the Y coordinate so it can perturb the caves vertically. Re-using the ground surface noise with an extra multiplier can prove effective sometimes, so we avoid computing extra noise.
|
||||
|
||||
|
||||
|
||||
|
||||
The second problem can also be fixed with yet another layer of low-frequency noise, which can be added to the cave threshold so caves will shrink to become dead-ends on some regions. Again, adding multipliers may change how sharply that transition occurs.
|
||||
|
||||
|
||||
|
||||
|
||||
Finally, we can blend our terrain with caves by subtracting them. This can be done with the `SdfSmoothSubtract` node, essentially doing `terrain - caves`.
|
||||
|
||||
|
||||
|
||||
|
||||
There are likely variants of this to obtain different results.
|
||||
|
||||
@ -186,15 +186,15 @@ It is possible to use this generator with `VoxelMesherBlocky` by using an `Outpu
|
||||
|
||||
The simplest example is to pick any existing SDF generator, and replace `OutputSDF` with a `Select` node connected to an `OutputType`. The idea is to choose between the ID of two different voxel types (like air or stone) if the SDF value is above or below a threshold.
|
||||
|
||||
|
||||
|
||||
|
||||
If more variety is needed, `Select` nodes can be chained to combine multiple layers, using different thresholds and sources.
|
||||
|
||||
|
||||
|
||||
|
||||
`Select` creates a "cut" between the two possible values, and it may be desirable to have some sort of transition. While this isn't possible with `VoxelMesherBlocky` without a lot of different types for each value of the gradient (usually done with a shader), it is however easy to add a bit of noise to the threshold. This reproduces a similar "dithered" transition, as can be seen in Minecraft between sand and dirt.
|
||||
|
||||
|
||||
|
||||
|
||||
Currently, graph generators only work per voxel. That makes them good to generate base ground and biomes, but it isn't practical to generate structures like trees or villages with it. This may be easier to accomplish using a second pass on the whole block instead, using a custom generator.
|
||||
|
||||
@ -211,7 +211,7 @@ Contrary to many node-based or expression tools existing in Godot so far, voxel
|
||||
|
||||
So instead, outputs of each node are associated small buffers for a subset of the voxels, say, a 16x16 slice. Then, the graph is traversed once ahead-of-time to obtain a simple list of operations. It is guaranteed that if a node depends on another, the other will have run before.
|
||||
|
||||
|
||||
|
||||
|
||||
Finally, the generator executes the list, node by node, and each node computes a bunch of voxels at once instead of just one. This ensures that the CPU is almost exclusively used for the operations themselves, providing performance similar to C++, while graph traversal becomes neglibible. It also offers the opportunity to use [SIMD](https://en.wikipedia.org/wiki/SIMD) very easily, which can be even faster than if the code was written in plain C++.
|
||||
|
||||
@ -223,11 +223,11 @@ Before processing voxels in a specific region of space (a box), the generator fi
|
||||
|
||||
It is possible to inspect results of this pass in the editor by enabling it with the `Analyse range` button. The analysis will focus on the box specified in the dialog, which will appear as a yellow wireframe in the 3D viewport.
|
||||
|
||||
|
||||
|
||||
|
||||
You can also hover the output label of any node to see what range was calculated for it:
|
||||
|
||||
|
||||
|
||||
|
||||
!!! note
|
||||
Noise is typically between -1 and 1, but we take it a step further. Ranges are approximated using maximum derivatives, which is how fast noise can vary along a given distance. Each noise algorithm has its own. We calculate noise at the center of the box, and add half of the maximum derivative, positively and negatively. In other words, in the box, we know noise cannot exceed the central value + the maximum variation along extents of the box. At close range, this can successfully detect valleys and hills, without fully computing them.
|
||||
@ -244,17 +244,17 @@ It is possible to choose that threshold with the `sdf_clip_threshold` property i
|
||||
|
||||
It is exposed because in some situations, clipping can cause artifacts when the edge of a block is too close from a clipped one. Indeed, clipping blocks cause discontinuities in the distance field.
|
||||
|
||||
|
||||
|
||||
|
||||
Usually they happen far enough from the surface to be of any concern, but sometimes they can come close if the threshold is too low:
|
||||
|
||||
|
||||
|
||||
|
||||
So by default the threshold is above zero and should cover most cases.
|
||||
|
||||
It is also possible to instruct the generator to invert clipped blocks, which will make them stand out:
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
#### Local optimization
|
||||
@ -263,11 +263,11 @@ Conditionals (`if/else`) are not supported by this voxel graph implementation. T
|
||||
|
||||
Let's consider an example world made of two biomes, each generated with a big node setup, and blended together across the world's X axis.
|
||||
|
||||
|
||||
|
||||
|
||||
If we don't optimize this, both biomes will constantly get calculated at every point of space close enough to the surface. But if we look at the range analysis we performed earlier, and focus on one of the biomes, we notice that the range of values received by the `Mix` node are such that only one biome is blended. In other words, one of the inputs of `Mix` has no effect on its result, and is therefore ignored there.
|
||||
|
||||
|
||||
|
||||
|
||||
So each biome then only computes its own branch when far away enough from the blending area:
|
||||
|
||||
@ -277,7 +277,7 @@ Thanks again to range analysis, the generator is able to detect this locally, an
|
||||
|
||||
Internally, the generator parses the graph locally (using a faster data structure since the graph is compiled) to obtain an alternative list of operations. This list is currently nicknamed an `execution map`, because it maps the full list of operations to a reduced one.
|
||||
|
||||
|
||||
|
||||
|
||||
This setting can be toggled in the inspector.
|
||||
|
||||
|
||||
@ -26,7 +26,7 @@ A new build is made each time commits are pushed to the main branch, but also wh
|
||||
|
||||
In case there are multiple downloadable artifacts, the editor build will be the one with `opt.tools` in the name (because it is built with optimizations enabled, and includes tools).
|
||||
|
||||
|
||||
|
||||
|
||||
!!! note
|
||||
You will need a Github account to be able to download development builds. Otherwise, links will not work.
|
||||
|
||||
|
Before Width: | Height: | Size: 747 KiB |
BIN
doc/source/images/biomes.webp
Normal file
|
After Width: | Height: | Size: 506 KiB |
|
Before Width: | Height: | Size: 775 KiB After Width: | Height: | Size: 629 KiB |
|
Before Width: | Height: | Size: 558 KiB |
BIN
doc/source/images/blender_block_uv_mapping.webp
Normal file
|
After Width: | Height: | Size: 282 KiB |
|
Before Width: | Height: | Size: 155 KiB |
BIN
doc/source/images/blender_face_cube_side.webp
Normal file
|
After Width: | Height: | Size: 84 KiB |
|
Before Width: | Height: | Size: 16 KiB |
BIN
doc/source/images/block_map_storage.webp
Normal file
|
After Width: | Height: | Size: 4.0 KiB |
|
Before Width: | Height: | Size: 6.7 KiB |
BIN
doc/source/images/blocky_game_atlas.webp
Normal file
|
After Width: | Height: | Size: 2.3 KiB |
|
Before Width: | Height: | Size: 774 KiB |
BIN
doc/source/images/blocky_screenshot.webp
Normal file
|
After Width: | Height: | Size: 446 KiB |
|
Before Width: | Height: | Size: 493 KiB |
BIN
doc/source/images/blocky_sdf.webp
Normal file
|
After Width: | Height: | Size: 326 KiB |
|
Before Width: | Height: | Size: 44 KiB |
BIN
doc/source/images/cave_threshold_modulation.webp
Normal file
|
After Width: | Height: | Size: 19 KiB |
|
Before Width: | Height: | Size: 622 KiB |
BIN
doc/source/images/caves_composed.webp
Normal file
|
After Width: | Height: | Size: 436 KiB |
|
Before Width: | Height: | Size: 395 KiB |
BIN
doc/source/images/caves_flat.webp
Normal file
|
After Width: | Height: | Size: 279 KiB |
|
Before Width: | Height: | Size: 424 KiB |
BIN
doc/source/images/caves_perturb.webp
Normal file
|
After Width: | Height: | Size: 294 KiB |
|
Before Width: | Height: | Size: 348 KiB |
BIN
doc/source/images/caves_perturb_modulated.webp
Normal file
|
After Width: | Height: | Size: 239 KiB |
|
Before Width: | Height: | Size: 13 KiB |
BIN
doc/source/images/cube_tile_coordinates.webp
Normal file
|
After Width: | Height: | Size: 5.9 KiB |
|
Before Width: | Height: | Size: 101 KiB |
BIN
doc/source/images/cubes_and_marching_cubes.webp
Normal file
|
After Width: | Height: | Size: 49 KiB |
|
Before Width: | Height: | Size: 1.4 MiB |
BIN
doc/source/images/cubes_and_wireframe.webp
Normal file
|
After Width: | Height: | Size: 1.1 MiB |
|
Before Width: | Height: | Size: 804 KiB |
BIN
doc/source/images/editor_preview_smooth_2d_noise_terrain.webp
Normal file
|
After Width: | Height: | Size: 494 KiB |
|
Before Width: | Height: | Size: 76 KiB |
BIN
doc/source/images/fixed_bounds_octrees.webp
Normal file
|
After Width: | Height: | Size: 36 KiB |
|
Before Width: | Height: | Size: 487 KiB |
BIN
doc/source/images/flat_shading.webp
Normal file
|
After Width: | Height: | Size: 325 KiB |
|
Before Width: | Height: | Size: 1.1 MiB |
BIN
doc/source/images/game_examples.webp
Normal file
|
After Width: | Height: | Size: 816 KiB |
|
Before Width: | Height: | Size: 350 KiB |
BIN
doc/source/images/generator_flat.webp
Normal file
|
After Width: | Height: | Size: 247 KiB |
|
Before Width: | Height: | Size: 885 KiB |
BIN
doc/source/images/generator_image.webp
Normal file
|
After Width: | Height: | Size: 572 KiB |
|
Before Width: | Height: | Size: 719 KiB |
BIN
doc/source/images/generator_noise2d.webp
Normal file
|
After Width: | Height: | Size: 453 KiB |
|
Before Width: | Height: | Size: 892 KiB |
BIN
doc/source/images/generator_noise3d.webp
Normal file
|
After Width: | Height: | Size: 597 KiB |
|
Before Width: | Height: | Size: 543 KiB |
BIN
doc/source/images/generator_waves.webp
Normal file
|
After Width: | Height: | Size: 388 KiB |
|
Before Width: | Height: | Size: 14 KiB |
BIN
doc/source/images/github_actions_windows_artifacts.webp
Normal file
|
After Width: | Height: | Size: 5.5 KiB |
|
Before Width: | Height: | Size: 944 KiB |
BIN
doc/source/images/graph_in_editor_with_fast_noise_lite.webp
Normal file
|
After Width: | Height: | Size: 589 KiB |
|
Before Width: | Height: | Size: 17 KiB |
BIN
doc/source/images/instance_library_menu.webp
Normal file
|
After Width: | Height: | Size: 6.5 KiB |
|
Before Width: | Height: | Size: 567 KiB |
BIN
doc/source/images/instances_lod_index.webp
Normal file
|
After Width: | Height: | Size: 371 KiB |
|
Before Width: | Height: | Size: 767 KiB |
BIN
doc/source/images/instances_procgen.webp
Normal file
|
After Width: | Height: | Size: 477 KiB |
|
Before Width: | Height: | Size: 1.0 MiB |
BIN
doc/source/images/landscape_with_instances.webp
Normal file
|
After Width: | Height: | Size: 754 KiB |
|
Before Width: | Height: | Size: 68 KiB |
BIN
doc/source/images/lod_density_schema.webp
Normal file
|
After Width: | Height: | Size: 16 KiB |
|
Before Width: | Height: | Size: 647 KiB |
BIN
doc/source/images/lod_example.webp
Normal file
|
After Width: | Height: | Size: 446 KiB |
|
Before Width: | Height: | Size: 28 KiB |
BIN
doc/source/images/material_blocky_game.webp
Normal file
|
After Width: | Height: | Size: 17 KiB |
|
Before Width: | Height: | Size: 12 KiB |
BIN
doc/source/images/menu_regenerate.webp
Normal file
|
After Width: | Height: | Size: 5.8 KiB |
|
Before Width: | Height: | Size: 12 KiB |
BIN
doc/source/images/menu_stream_follow_camera.webp
Normal file
|
After Width: | Height: | Size: 5.8 KiB |
|
Before Width: | Height: | Size: 25 KiB |
BIN
doc/source/images/mesh_lod_properties.webp
Normal file
|
After Width: | Height: | Size: 9.3 KiB |
|
Before Width: | Height: | Size: 992 KiB |
BIN
doc/source/images/mesh_lods.webp
Normal file
|
After Width: | Height: | Size: 700 KiB |
|
Before Width: | Height: | Size: 637 KiB |
BIN
doc/source/images/misaligned_instances.webp
Normal file
|
After Width: | Height: | Size: 415 KiB |
|
Before Width: | Height: | Size: 16 KiB |
BIN
doc/source/images/noise.webp
Normal file
|
After Width: | Height: | Size: 7.8 KiB |
|
Before Width: | Height: | Size: 149 KiB |
BIN
doc/source/images/range_analysis_dialog.webp
Normal file
|
After Width: | Height: | Size: 93 KiB |
|
Before Width: | Height: | Size: 6.4 KiB |
BIN
doc/source/images/range_analysis_tooltip.webp
Normal file
|
After Width: | Height: | Size: 3.2 KiB |
|
Before Width: | Height: | Size: 12 KiB |
BIN
doc/source/images/range_of_ignored_input.webp
Normal file
|
After Width: | Height: | Size: 5.5 KiB |
|
Before Width: | Height: | Size: 122 KiB After Width: | Height: | Size: 86 KiB |
|
Before Width: | Height: | Size: 397 KiB |
BIN
doc/source/images/sdf_clip_debug.webp
Normal file
|
After Width: | Height: | Size: 239 KiB |
|
Before Width: | Height: | Size: 16 KiB |
BIN
doc/source/images/sdf_clipping.webp
Normal file
|
After Width: | Height: | Size: 10 KiB |
|
Before Width: | Height: | Size: 277 KiB |
BIN
doc/source/images/sdf_clipping_artifacts.webp
Normal file
|
After Width: | Height: | Size: 163 KiB |
|
Before Width: | Height: | Size: 282 B |
BIN
doc/source/images/sdf_example_blocky.webp
Normal file
|
After Width: | Height: | Size: 90 B |
|
Before Width: | Height: | Size: 1.6 KiB |