



I decided to slowly start sharing the VertexArt project with you. Currently you can test these demos: Infinite demo, PlyEditor, Terrain Editor, Mini demo games. You can find my hosting in the comments. I would be happy to receive feedback from you. VertexArt has been in development for just 4 months, it's a very new project, but I hope I can achieve my goals. (loot, craft, vehicle driving, roaming, mission system, building development, GTA 5 RP-like work, processing classic games in the VertexArt style )
VertexArt, István Kovács, 2026
Development LOG:
May 11
2D square & OpenGL 3.3 stable connection
procedural, moving, infinite road with fog
May 16
Static Mesh editor with procedural objects, no export
May 18
3D generated cubes rotate scaled, stretched
Ply cube rotates scaled, stretched
May 19
ply car rotates in 4 positions with nice shader
May 26
FPP camera movement around ply object (space raises camera, ctrl lowers, WASD controls with mouse)
TPP vehicle with simple physics on plane (speeds up, slows down turns)
E key gets in/out
vehicle camera: C: tpp, top-down, interior
May 30
vehicle tilts according to control
June 5.
Static Mesh Editor gets export function
June 6
frame limiter
June 19
Applying a track edited in Static Mesh Editor in a demo game with a vehicle
the vehicle gets a handbrake
July 1
Infinite driving with teleport function
Raycast development
first raycast test: thanks to stable modules, Ai generated a polygon coloring application in 3 minutes which worked flawlessly on the first compile!!
(right click takes color, left click colors, nothing more)
July 3
BVH and collision detection with static mesh terrain
July 7
ChunkBatch
July 8
FPP camera walking with perfect raycast on static mesh terrain
July 9
Mesh Editor and PLY Editor get chunk system for handling huge spaces
July 20
26 million vertex world generated in tilemap mode using Static Mesh Editor
(a huge island unloaded 5x)
the game demo prepared for Static terrain handled the 26 million vertex world stably!
July 26
Terrain Editor with chunk/bvh features for handling huge areas, but no ply loading yet
August 2
Module development:
scene management
lighting system
physics system (bodies and collisions)
gizmo
picking
shader programs for light, time of day, lines, artistic rendering
August 6
Terrain Editor gets ply support, features perfected
further work on character and vehicle physics, collision detection.
The Problem
In a chunk-based terrain editor, brushing (Raise/Lower/Smooth) modifies the Y coordinates of vertices every single frame. The naive solution rebuilds the BVH (BuildBVH) and reloads the entire VBO (UploadChunkToGPU) for every modified chunk. This operation is slow because BVH construction is O(n log n), and reloading the full VBO copies a lot of data to the GPU. During continuous brushing (holding the mouse button), this runs every frame, causing stuttering with higher vertex densities.
The Essence of the Trick
Brushing only changes the Y coordinates. The X and Z coordinates remain unchanged. This enables the following:
· Use glBufferSubData to update the VBO instead of reloading the entire buffer. Only the modified vertex data is sent to the GPU.
· Defer BVH rebuilding until the mouse button is released. Since the BVH bounding boxes are unchanged in the X-Z plane, the BVH remains a valid acceleration structure. Raycasts will still find the potentially affected triangles, and the actual ray-triangle intersection test is performed on the updated CPU-side Vertices array, so the hit point's Y coordinate remains accurate.
Implementation Outline
· Track modified chunks in a static array (max 9 chunks, because the brush covers a 3x3 area).
· During brushing: modify the Y values on the CPU, then update the VBO with glBufferSubData. Do not set the Dirty flag, so UpdateDirtyChunks does not run.
· Store the index of the modified chunk in a list.
· When the mouse button is released, iterate through the list, set the Dirty flag, call UpdateDirtyChunks (which rebuilds the BVH), and then clear the list.
· In the main loop, keep the call to UpdateDirtyChunks only when there is no active brushing – so BVH construction does not interfere with continuous operation.
Why It Works
The BVH is only an acceleration structure that filters candidate triangles based on their X-Z positions. Since the X-Z coordinates do not change, the BVH continues to correctly return the potential triangles. The actual intersection calculation is performed on the CPU with the updated Y values, so the hit point remains accurate. This approach yields a significant performance increase without sacrificing functionality or precision.
Limitations
· Only works when modifications affect exclusively the Y coordinates.
· If X or Z also change (e.g., rotation, translation), the BVH must be rebuilt immediately.
· The BVH remains only an acceleration structure; the precise intersection calculation still occurs on the CPU.
This performance optimization would not have come about if I had developed in a more modern PC environment; I would not have noticed the slowdown. It is still an Intel N4100 CPU that reveals when something is not working optimally. From my recent development work, it is clear why Free Pascal 3.2.2 became my choice for implementing the VertexArt project! I just had to build a reliable architecture.
VertexArt - TERRAIN EDITOR
TECHNICAL AND FUNCTIONAL DOCUMENTATION
Developer: Kovács István
Development environment: Free Pascal / OpenGL 3.3
Platform: Windows (GLFW3)
VertexArt Terrain Editor is a desktop application designed for interactive terrain editing of models stored in PLY (Polygon File Format) files.
The program enables real-time, stable, and user-friendly modification of large models consisting of several million triangles – in the form of raising, lowering, smoothing, flattening, and ramp creation.
The software is specifically optimized for low-power processors (e.g., Intel N4100) and integrated GPUs (iGPU), but it runs on any hardware supporting OpenGL 3.3.
The program has a modular structure, divided into the following main components:
· SterilTypes: Basic data types (TVector3, TVector4, TVertex, TMat4).
· SterilMath / Vector: Vector and matrix operations (addition, multiplication, normalization, transformations).
· SterilWindow: Window management (GLFW3 initialization, framebuffer callback).
· SterilCamera: FPS camera (WASD movement, mouse look, sprint, height adjustment).
· ShaderManager: Shader compilation and program creation (ColorProg, LineProg).
· Renderer / RenderQueue: Rendering pipeline (Color pass).
· PLYLoader: Loading ASCII PLY files into a triangle mesh.
· UChunkSystem: Chunk system – splitting the model into 16×16 meter blocks, managing active chunks (9×9), building and maintaining BVH.
· ChunkBVH: BVH tree construction and raycast (ITriProvider interface).
· Raycast / RaycastTypes: Ray–triangle intersection (Möller-Trumbore), AABB, TRaycastHit.
· FrameLimiter: 30 FPS limit (spin wait + Sleep).
· TerrainBrush: Implementation of brush operations (Raise, Lower, Smooth, Flatten, Ramp).
· TerrainIO: PLY export (timestamped saving).
Data flow:
PLY file -> PLYLoader -> UChunkSystem (chunks + BVH) -> GPU (VAO/VBO)
-> Editing (brush) -> UpdateDirtyChunks (GPU update + BVH rebuild)
-> Export (PLY)
Chunk system details:
· The model is divided into 16×16 meter blocks (chunks).
· Only a 9×9 chunk area (81 chunks) around the camera is active for rendering and brush operations.
· Raycast (selection) runs on the BVH structure of 3×3 chunks (9 chunks), so speed does not depend on the total model size.
· Each chunk has its own VAO/VBO pair and BVH.
· After modification, a chunk receives a Dirty flag, and in the next frame the GPU buffer and BVH are automatically rebuilt.
Rendering:
· Color pass – the ColorProg shader includes lighting (diffuse, ambient, specular, fresnel).
· Wireframe mode – using the LineProg shader, the entire active area is displayed as a green wireframe, showing only lines (without polygon fill).
· Frame limiter – limits screen refresh to 30 FPS.
Editing modes:
Raise: Raises the terrain under the brush.
Lower: Lowers the terrain under the brush.
Smooth: Averages the heights within the brush area, creating a uniform surface.
Flatten: With a single click, pulls the entire brush area to the height of the clicked point.
Ramp: Creates a cosine-transition ramp between two points (left and right click). The ramp width is proportional to the brush size, with an inner band and smooth transition at the edges.
Selection and visual feedback:
· BVH raycast: a ray cast at the click position immediately determines the selected triangle and its position.
· Brush circle: a translucent orange circle appears around the selected point, showing the brush size and location.
· Wireframe mode: pressing F2 displays the entire active area as a green wireframe without polygon fill – making the geometry structure clearly visible.
Brush operations in detail:
· Raise / Lower: The effect decreases quadratically with distance from the brush center, creating a smooth transition toward the edges.
· Smooth: Calculates the average height of all vertices under the brush, then moves vertices toward this average according to brush strength.
· Flatten: A single click – all vertices within the brush area are set exactly to the height of the clicked point. No holding or repeated clicking is required.
· Ramp: A linear height transition is created between the start point selected by left click and the end point selected by right click. The brush radius determines the ramp width, within which:
· an inner band (60% of the radius) is applied at full strength,
· toward the edges a cosine transition ensures smooth blending.
Feedback and state:
· During editing, height changes appear immediately on screen because the GPU buffer is refreshed at the end of every frame (UpdateDirtyChunks).
· Brush size can be adjusted with the scroll wheel (0.3 – 5.0 meters).
Automatic terrain generation:
· If terrain.ply is not found in the program directory at startup, the system automatically generates a 100×100 meter flat terrain with 50×50 resolution (with a colored checkerboard pattern), so the user can immediately test editing.
Saving and export:
· F12: exports the entire model to ASCII PLY format.
· During saving, all chunks are merged, triangles receive new indexing, and the filename automatically gets a timestamp (terrain_yyyy-mm-dd_hh-nn-ss.ply).
· F9: reloads the terrain.ply file (or generates it if it does not exist).
Camera and navigation:
· WASD: move forward/backward/sideways
· Shift: sprint (faster movement)
· Space: raise camera
· Ctrl: lower camera
· Mouse: look rotation (when mouse capture is enabled)
· F1: toggle mouse capture (cursor lock)
· ESC: exit
Performance on integrated GPU (iGPU):
The program runs on integrated GPUs, but performance depends on geometry distribution.
· Advantageous case: low-poly geometry over a large area (up to a 130×130 km world). The 9×9 chunk system and BVH raycast enable smooth handling of several million vertices. Successful tests: loading and editing 25 million vertices on an N4100 CPU.
· Limited case: If several million vertices are concentrated in a small area (e.g., a high-poly vehicle), rendering and raycast may slow down on iGPU because chunks become overloaded and BVH is less effective. In this case, the program still works, but interactive speed may decrease.
Summary: Due to the chunk size (16 m) and the 9×9 active area, the program provides the best performance in large-scale, but geometrically simple (low-poly) scenes.
Optimization strategies:
· Chunking: Only 81 chunks around the camera are active.
· BVH: Raycast runs on the BVH of 3×3 chunks, so search time is logarithmic.
· UpdateDirtyChunks: BVH rebuild occurs only at the end of the frame, not on every brush stroke.
· glPolygonOffset: Wireframe overlay is z-fighting free.
· Frame limiter: 30 FPS using spin wait + Sleep combination.
Advantages:
· Speed: With the chunk+BVH combination, raycast and rendering remain smooth even with millions of triangles, provided geometry is distributed over a large area (low-poly world).
· Simplicity: No complex UI is needed – every function is accessible via keyboard shortcuts.
· Precision: Flatten works with a single click, Ramp uses cosine transition, so the surface is smooth and natural.
· Stability: Memory management is safe, no leaks, and the program does not crash even on large models.
· Focus: Specifically optimized for terrain editing, unlike general-purpose tools.
Keys and operations:
1: Raise
2: Lower
3: Smooth
4: Flatten – single click
5: Ramp
Left click: Execute operation (Raise/Lower/Smooth by holding, Flatten/Ramp by single click)
Shift + Left click: Lower (quick lowering)
Right click: Select ramp endpoint
WASD: Camera movement
Shift: Sprint (fast movement)
Space: Raise camera
Ctrl: Lower camera
F1: Toggle mouse capture (cursor lock)
F2: Toggle wireframe mode
F9: Load PLY (terrain.ply)
F12: Export PLY (with timestamp)
ESC: Exit
Workflow – example:
Start: The program loads terrain.ply or generates a default terrain.
Navigate: Use WASD + mouse to set the desired viewpoint.
Brush size: Adjust brush radius with the scroll wheel (0.3 – 5.0 meters).
Select mode: Press one of the keys 1–5.
Edit:
· Raise/Lower/Smooth: hold the left mouse button and move the mouse.
· Flatten: click once on the terrain – the brush area is immediately flattened.
· Ramp: left click for the start point, right click for the end point – the ramp is created instantly.
Wireframe: Press F2 to enable the green wireframe for better overview (without fill).
Save: F12 – the program saves the current state to a timestamped PLY file.
CLOSING THOUGHTS
VertexArt Terrain Editor is a tool that combines speed, precision, and simplicity. It does not try to do everything, but what it does, it does efficiently and stably.
The chunk system, BVH, and 30 FPS frame limiter together enable smooth work even on low-poly terrains with several million triangles, especially in large-scale scenes. The program also runs on iGPU, but performance depends on geometry density and distribution – it is unbeatable in low-poly, large-scale worlds.
The code is clean and well-structured; the strict coding style and memory management strategy guarantee long-term stability.
VertexArt - PLY EDITOR - TECHNICAL AND FUNCTIONAL DOCUMENTATION
Developer: Kovács István
Development Environment: Free Pascal / OpenGL 3.3
Platform: Windows (GLFW3)
---
The PLY Editor is a desktop application designed for interactive coloring, geometric correction, and saving of PLY (Polygon File Format) files. The program enables real-time, stable, and user-friendly editing operations even on large 3D models consisting of millions of triangles.
The software is specifically optimized for the N4100 low-power CPU and integrated GPUs (IGPU), but it runs on any hardware supporting OpenGL 3.3.
---
The program has a modular structure consisting of the following units:
· SterilTypes: Basic data types (TVector3, TVector4, TVertex, TMat4).
· SterilMath: Vector and matrix operations (Vec3, VecAdd, VecSub, VecScale, VecDot, VecCross, VecNormalize, Identity, Translate, RotateY, Scale, Multiply, Perspective, LookAt).
· SterilWindow: Window management (GLFW3 initialization, window creation, framebuffer callback).
· SterilCamera: FPS camera handling (movement, mouse, physics: gravity, jumping, crouching, sprinting, prone position).
· RenderTypes: Render command definitions (TRenderCommand).
· RenderQueue: Collection and sorting of render commands.
· RenderState: OpenGL state management (depth test, cull face, color mask).
· Renderer: Depth prepass + Color pass rendering (TShaderProgramRef, TDepthProgramRef, TRenderer).
· ShaderManager: Shader compilation, linking, and creation (Depth, Color, EditorColor, Line shaders).
· PLYLoader: PLY file loading in ASCII format (TPLYMesh).
· SterilMeshUtils: Mesh normalization (centering, ground alignment).
· PLYChunkSystem: Chunk system (16×16 meter blocks), BVH construction and management.
· ChunkBVH: BVH tree construction and raycasting (TBVH, ITriProvider).
· Raycast: Ray–triangle intersection (Möller–Trumbore algorithm).
· RaycastTypes: Type definitions for raycasting (TRay, TAABB, TTriangle, TRaycastHit, TBVH).
· Vector: Additional vector operations (VecDistance, VecLength).
· FrameLimiter: 30 FPS limiting (spin wait, sleep).
The main program (plycolor.pas) uses these units and contains the editor logic (selection, modes, pulsing, outlines, undo, export, keyboard and mouse handling).
Data Flow:
PLY file → PLYLoader → Chunk system (with BVH) → GPU → Editing → Export
Chunk System:
· The model is divided into 16×16 meter blocks (chunks).
· Only the 9×9 chunks (81 total) around the camera are active for rendering.
· Raycasting (selection) runs on the BVH structures of 3×3 chunks (9 total), so speed is independent of the total model size.
· Each chunk has its own VAO/VBO pair and BVH.
Rendering:
· Depth prepass + Color pass technique (two-stage rendering).
· The coloring shader includes fresnel and specular effects, but the editor version is fog-free for clear visibility.
· A frame limiter restricts screen refresh to 30 FPS, preventing excessive CPU load.
---
Editing Modes:
· Paint Mode (1): Colors a triangle with the selected color.
· Delete Mode (2): Deletes a triangle (undoable).
· Flip Mode (3): Reverses a triangle's normal (swaps vertex order).
Selection and Visual Feedback:
· BVH-based raycasting: A ray cast at the click position instantly selects the nearest triangle.
· Pulsing: The selected triangle's color pulses (brightens/darkens) toward the selected color.
· Outlines: A colored line is drawn around back-facing (incorrectly oriented) triangles. Green in Paint mode, red in Delete mode, yellow in Flip mode.
· Outlines always appear only on invisible polygons, allowing the user to see exactly which triangles face the wrong direction.
Color Management:
· Color selection: Right mouse button on the selected triangle → the color is stored.
· Painting: Left mouse button applies the selected color (or white if no color is selected).
· Original colors are preserved during pulsing, ensuring accurate restoration at all times.
Undo:
· In Delete mode, right mouse button → undoes the last deletion.
· The system stores the last 50 deletions (at the chunk level).
· The BVH is automatically rebuilt during restoration.
Saving:
· F12: Exports the entire model to ASCII PLY format.
· During saving, all chunks are merged and triangles receive new indexing.
· The filename automatically receives a timestamp.
Camera and Navigation:
· WASD: Movement
· Shift: Sprint (fast movement)
· Space: Up, Ctrl: Down
· Mouse: View rotation (camera orbit)
· F1: Toggle mouse capture
· F11: Toggle fullscreen
Automatic Camera Positioning:
Based on the loaded model's dimensions, the program determines whether it is a terrain (large, flat model) or an object (smaller, walkable), and positions the camera accordingly. For terrain: top-down view (pitch: -90°), for objects: side view (pitch: 0°).
---
Performance on Integrated GPUs (IGPU):
The program runs on integrated GPUs, but performance depends on geometry distribution.
Advantageous case: Low-poly geometry over large areas (up to a 130×130 km world with Synty Studios-style objects). In this case, the 9×9 chunk system and BVH raycasting enable smooth handling of millions of vertices. Successful tests include loading and editing 25 million vertices with the VertexArt Mesh Editor, as well as tiling a complete city 5× in tilemap mode to create a vast space.
Limited case: If millions of vertices are concentrated in a small area, rendering and raycasting may slow down on IGPU because chunks become overloaded and BVH efficiency decreases. The program continues to function, but interactive speed may degrade. For reference, a LOW POLY demo city contains approximately 5 million vertices, but a HIGH POLY vehicle can consume even more vertices than that, so conscious planning is important on iGPU.
Due to the chunk size (16 m) and the 9×9 active range, the program delivers the best performance in large-scale, geometrically simple (low-poly) scenes.
---
Advantages:
· Speed: With the chunk+BVH combination, raycasting and rendering remain fluid even with millions of triangles, provided geometry is distributed over large areas (low-poly worlds).
· Simplicity: No complex UI required – all functions are accessible via keyboard shortcuts.
· Precision: Back-face detection and pulsing instantly indicate incorrectly oriented polygons.
· Stability: Memory management is safe, no leaks, the program does not crash on large models.
· Focus: Specifically optimized for PLY files, unlike general-purpose tools.
---
Keys and Operations:
· 1: Paint mode
· 2: Delete mode
· 3: Flip mode
· Left click: Execute operation
· Right click: Select color (Paint) / Undo (Delete)
· WASD: Camera movement
· Shift: Sprint
· Space: Up
· Ctrl: Down
· F1: Toggle mouse capture
· F11: Toggle fullscreen
· F12: Export PLY
· ESC: Exit
---
The PLY Color Editor is a tool that combines speed, precision, and simplicity. It does not attempt to do everything, but what it does, it does efficiently and stably. The chunk system, BVH, and 30 FPS frame limiter together enable smooth work even on models with millions of triangles, particularly in large-scale scenes. The program runs on iGPU, but performance depends on geometry density and distribution.
The code is clean and well-structured, with a strict coding style and memory management strategy that guarantees long-term stability.
Here is a summary of some of the technological advantages of the VertexArt game engine that make it uniquely suited to handling a 3D city (like Synty Studios):
\* 16-byte vertex size and texture-free architecture
The models use pure vertex coloring without textures or UV coordinates. This requires minimal memory bandwidth, so data can be squeezed across hardware buses at lightning speed.
\* The entire game world is permanently in RAM
Since the entire 3D geometry is extremely small (e.g. 50 million vertices are only \~763 MB), the entire layer set can be loaded into memory at once.
\* No runtime streaming (I/O) required
Since all data is permanently in RAM, the micro-stutter (stutter) and delayed loading of objects (asset-pop) typical of modern games are completely eliminated.
\* I switched to a hybrid SOA and AOS memory structure.
This ensures maximum hardware efficiency.
\* BVH-based spatial analysis and pre-computed visibility mask. With the combination of the Chunk system, Bounding Volume Hierarchy and pre-computed mask, the CPU filters out invisible city areas in nanoseconds.
\* Hardware-tuned depth pre-pass (Z-Prepass)
In dense urban spaces, hidden surfaces behind walls (overdrawing) do not burden the graphics card. The depth buffer built in the first pass guarantees that the GPU only renders what is actually visible.
\* Instant raycast. Since the entire world geometry and BVH tree are constantly present in RAM, raycasts and body collisions (OBB vs. BVH) can be run at fixed intervals at any point in the track.
If you have any questions or comments about my project, I would be happy to hear from you. I have already achieved the most important basics for me, there is still a lot to improve, but what I have been able to bring to life so far is very effective.
Tools included:
Raise – push terrain up
Lower – push terrain down
Smooth – average out heights for a gentle blend
Flatten – level an area to a constant height
Ramp – create a smooth, driveable slope between two points (brush radius controls the width!)
Controls:
Left-click and drag to sculpt continuously
Hold Shift + left-click to lower instead of the current mode
Scroll wheel to adjust brush size
F2 to toggle wireframe mode
F1 to lock/unlock mouse capture
F12 to export the terrain as a PLY file
The character currently moves using 8 raycasts: 2 at the feet, 2 at the knees, 1 at the waist, 1 at the chest, and 2 at the shoulders. This setup works reasonably well for general traversal, but unfortunately, it still passes through thin obstacles like railings.
For the future, I plan to keep the feet raycasts for terrain and stair detection, but I will add 2 additional sphere casts for wall collision. Even with the current system, however, the character is already capable of free-roaming across the terrain.
I used a pre-computed visibility system.
The terrain is divided into pieces and visibility is determined using pre-computed masks for 32 viewing directions. At runtime, the engine selects the appropriate mask instead of testing each piece separately.
Free Pascal 3.2.2 / GLFW3 / OpenGL 3.3 / DOD & SOA
Pure Free Pascal 3.2.2 / GLFW3 / OpenGL 3.3 / DOD & SOA
Hi everyone!
I’d like to share some demo videos of my continuously developing game engine project.
The project is written in pure Free Pascal 3.2.2, using GLFW3 and OpenGL 3.3 Core. It is not based on any existing game engine — I am developing the engine systems and rendering from scratch.
So far, I have only uploaded shorter demo videos, but I wanted to show the current state of the project and share my progress with the development community.
YouTube playlist:
https://youtube.com/playlist?list=PLX4BUpd-V-hI&si=X6aTdAFoJc5_-iDa
Thank you for taking a look!
Sziasztok!
Szeretném megosztani veletek néhány demóvideómat a folyamatosan fejlődő játékmotoromról.
A projekt tiszta Free Pascal 3.2.2 nyelven készül, GLFW3 és OpenGL 3.3 Core használatával. Nem meglévő játékmotorra épül. Eddig csak rövidebb demóvideókat töltöttem fel, de szeretném megmutatni, hogy jelenleg hol tart a projekt, és megosztani a fejlődését a fejlesztőkkel.
Lejátszási lista:
https://youtube.com/playlist?list=PLX4BUpd-V-hI&si=X6aTdAFoJc5_-iDa
Köszönöm, ha megnézitek!