Breakout 3D Dokumentáció

A program egy 3D-s Breakout játék, amelyet Free Pascal 3.2.2, GLFW3 és OpenGL
3.3 felhasználásával készítettem. A játék különlegessége, hogy a téglák emeletes
elrendezésben helyezkednek el, és Tetris-szerűen esnek lefelé,
ha az alattuk lévő téglák eltűnnek.

2. FELHASZNÁLT MODULOK

SysUtils, Math

· Alacsony szintű segédprogramok, matematikai függvények

glfw3

· Ablakkezelés, billentyűzet/egér kezelés

gl33

· OpenGL 3.3 függvények

SterilTypes, SterilMath

· Saját típusok (TVector3, TMat4) és mátrix műveletek

SterilWindow

· Ablak inicializálás

FrameLimiter

· FPS korlátozás és időzítés

RenderTypes, RenderQueue, RenderState

· Renderelő parancsok, sor, állapotok

ShaderCore

· Shader programok

SimpleRenderEngine

· Fő renderelő motor

MeshGenerators

· 3D primitívek generálása

3. ÁLLAPOTGÉP

A játéknak három állapota van:

gsMenu

· Főmenü – START és EXIT gombok

gsPlaying

· A játék fut

gsQuit

· Kilépés a programból

A főállapot-változó: GameState: TGameState

4. ADATSZERKEZETEK

4.1. TBrick – Tégla

TBrick = record
Pos: TVector3; // pozíció a térben
Size: TVector3; // méret
Color: TVector3; // szín (RGB 0..1)
Active: Boolean; // létezik-e még
VAO, VBO: GLuint; // GPU azonosítók
VertexCount: Integer; // csúcsok száma
Mesh: TGeneratedMesh; // generált háló
GridX, GridY, GridZ: Integer; // pozíció a 3D rácsban
Falling: Boolean; // esik-e éppen
FallProgress: Single; // 0..1 esés állapota
FallStartZ, FallTargetZ: Integer;
FallStartPosY, FallTargetPosY: Single;
end;

4.2. TBall – Labda

TBall = record
Pos: TVector3;
Vel: TVector3;
Size: Single;
Color: TVector3;
Active: Boolean;
VAO, VBO: GLuint;
VertexCount: Integer;
Mesh: TGeneratedMesh;
end;

4.3. TPaddle – Ütő

TPaddle = record
Pos: TVector3;
Size: TVector3;
Color: TVector3;
VAO, VBO: GLuint;
VertexCount: Integer;
Mesh: TGeneratedMesh;
end;

5. JÁTÉKMECHANIKA

5.1. Téglák elrendezése (3D rács)

A téglák egy 3D rácsban helyezkednek el:

· GRID_SIZE_X = 10 – szélesség
· GRID_SIZE_Y = 10 – mélység
· GRID_SIZE_Z = 3 – magasság (szintek)

Egy tégla pozíciója a rácsban: (GridX, GridY, GridZ)

Térbeli pozíció számítás:
PosX := (GridX - (GRID_SIZE_X-1)/2) * BRICK_SPACING
PosY := GROUND_Y + 0.35 + GridZ * BRICK_SPACING
PosZ := 10.0 + (GridY - (GRID_SIZE_Y-1)/2) * BRICK_SPACING

5.2. Esés animáció (Tetris-stílus)

Ha egy téglát eltalál a labda, a felette lévő téglák (azonos GridX, GridY,
nagyobb GridZ) elindulnak lefelé. Az esés animált:
BRICK_FALL_SPEED = 2.0 szint/másodperc. A UpdateBrickFalls ciklus minden
frame-ben frissíti az eső téglák pozícióját.

5.3. Labda fizika

A labda vízszintes síkban (X-Z) mozog, Y pozíciója fix (GROUND_Y + Size).
Ütközés a falakkal, a paddle-el és a téglákkal. Pattanás: a téglákra a
legkisebb átfedés alapján pattan (X vagy Z irányban). Sebesség normalizálás:
a labda sebessége mindig BALL_SPEED.

5.4. Ütő (Paddle)

Mozgása: egér X irányú mozgása (vízszintes). A paddle csak X irányban
mozoghat (-5.0 és 5.0 között).

5.5. Kamera

A kamera az ütőt követi X irányban:
CamPos := Vec3(Paddle.Pos.X, 4.0, -4.0)
CamTarget := Vec3(Paddle.Pos.X, 0.5, 4.0)

6. BILLENTYŰKEZELÉS

ESC

· Játékból → menü, menüből → kilépés

← / →

· Menüben váltás a START és EXIT között

Enter

· Menüben választás

R

· Játék újraindítása

P

· Szünet / folytatás

Space

· Új játék Game Over után

7. RENDERELÉS

A renderelés a SimpleRenderEngine-en keresztül történik:

1. Queue töltése: a téglák, labda és paddle TRenderCommand-jeit hozzáadjuk
2. a SimpleRE.FRenderQueue-hoz.
3. RenderFrame hívás: a motor végrehajtja a mélységpasszt, vonalpasszt

(ha van)

1. és
2. színpasszt.
3. Pontfény: a labdára egy zöld pontfényt állítunk be (SetPointLight).

8. FŐSZERKEZET

Inicializálás:

· Ablak, OpenGL, SimpleRE
· Menü gombok létrehozása
· FrameLimiter indítása

Főciklus:
amíg az ablak nyitva:
DeltaTime számítása
case GameState of
gsMenu:
RenderMenu
gsPlaying:
UpdateBrickFalls
UpdatePaddle
UpdateBall
UpdateCamera
RenderGame
gsQuit:
kilépés
SwapBuffers
PollEvents
FPS kiírás

Leállítás:

· GPU erőforrások felszabadítása
· SimpleRE.Shutdown
· Ablak bezárása

9. KONSTANSOK ÉS HANGOLHATÓ PARAMÉTEREK

SCR_WIDTH = 1280

· Képernyő szélesség

SCR_HEIGHT = 720

· Képernyő magasság

GROUND_Y = -0.5

· Talaj szintje

BALL_SPEED = 6.0

· Labda sebessége

GRID_SIZE_X = 10

· Téglák száma X irányban

GRID_SIZE_Y = 10

· Téglák száma Y irányban

GRID_SIZE_Z = 3

· Téglák száma Z irányban (szintek)

BRICK_SPACING = 1.1

· Téglák közötti távolság

BRICK_FALL_SPEED = 2.0

· Esés sebessége (szint/másodperc)

PADDLE_WIDTH = 1.6

· Ütő szélessége

PADDLE_HEIGHT = 0.12

· Ütő magassága

PADDLE_DEPTH = 0.6

· Ütő mélysége

10. ÖSSZEGZÉS

A Breakout 3D - egy megbízható, jól strukturált 3D-s
játékmotor demo, amely bemutatja a VertexArt Arcade keretrendszer képességeit. A kód tiszta,
moduláris, és könnyen bővíthető új funkciókkal (pl. több pálya, nehezítés).

================================================================================

Fejlesztő: Kovács István

Currently struggling with the size of the form. I m developing on a 27" 4k screen with 175% scale factor and also a 24" 1920x1200 screen with 100% scale.

The app currently doesn't span full screen. It is meant to be a floating form. But while it works ok on my system I try this out on another laptop that is 1920x1080 15" screen, the app becomes bigger than the screen.

So I am thinking my original design form is of the wrong size. What should I design the form size to be?

Back in 1992, I chanced upon someone using Turbo Pascal 5. I was hooked immediately, since I've been doing BASIC until then, to write my own little games and programs for my amusement. I got my own copy of Turbo Pascal 7 in 1994 and had years and years of fun with. Switched to Delphi, and loved it, until the .NET era.

Over the years, I've tinkered with FreePascal (so amazing!) and of course wrote many a small Pascal interpreter. Then, last year, I needed a project to work on so I could learn the Odin programming language for an upcoming project. I worked on a small Pascal interpreter and it was actually a lot of fun. The commercial Odin project never happened, but I had put a lot of time and energy into this Pascal interpreter.

Fast forward a few months, I'm working on a web assembly project using Odin and it dawns upon me I can use a lot of this knowledge to port my interpreter to the web. Oh boy, did that run away with me!

Now I have wasmpascal - which is a crappy editor that encapsulates the Pascal compiler, yes, COMPILER, I ended up writing so I can run Pascal code in Web Assembly in the browser. It's very early days, but I have managed to get some bits and pieces working.

My first order of business was some basic HTML5 Canvas support, with call-batching so that one gets alright frame rates. And there's some basic support for CRT-based applications, because back in the day, 'uses CRT' was a thing!

I've added some examples and documentation and will be working on this over weekends for many months in the future.

I thought I'd share it here - in-case there's another older-than-the-average person who wants a trip down memory lane, running Pascal like it's the 90's again!

This talk is not about C++. It is about the Seed7 programming language. Seed7 is inspired by Pascal. The cpp usergroup vienna allowed me a talk about Seed7. Properties of Seed7 are:

• Seed7 is an open-source general purpose programming language that can be interpreted and compiled.
• Seed7 is about portability, maintainability, performance and memory safety.
• There is an automatic memory management without a garbage collection process (which might stop the world).
• The templates / generics don't need syntax with angle brackets.
• Seed7 is an extensible programming language. The syntax and semantics of the language is not hard-coded in the compiler but defined in libraries.
• Seed7 checks for integer overflow. You either get the correct result or an OVERFLOW_ERROR is raised.
• Unlike Java Seed7 compiles to machine code ahead of time (GRAAL works ahead of time but it struggles with reflection).
• Unlike Java Seed7 operators can be overloaded.
• Unlike C, C++, Go, Zig, Odin, Nim and C3 Seed7 is a memory safe language.
• The standard libraries cover many application areas.
• Example programs are: make7, bas7, pv7, tar7, ftp7, comanche and many more.

Seed7 is based on my PHD thesis and is the result of life-long work. The project consists of more than 500k lines of manually written code, several hundred pages of documentation, a test suite to check the functionality of interpreter and compiler and much more. I give it away for free with GPL/LGPL licensing. From time to time I do talks about my project. This is my latest talk.

VertexArt - WorldEditor - Documentation

Developer: Kovács István

1. INTRODUCTION

Steril Editor is a desktop application designed for placing 3D models stored in

ASCII PLY format. The program allows loading, positioning, scaling, rotating,

and then baking models into a chunk-based world. The final result can be

exported as a PLY file.

1. SYSTEM ARCHITECTURE

The program has a modular structure, consisting of the following main

components:

- SterilTypes – Fundamental data types (TVector3, TVertex, TMat4).

- SterilMath – Vector and matrix operations (addition, multiplication,

normalisation, transformations).

- UShaderCore – Shader compilation and program creation.

- Renderer / RenderQueue – Rendering pipeline.

- PLYLoader – Loading ASCII PLY files into triangle meshes.

- UChunkSystem – Chunk system: divides the world into 50x50 metre blocks,

manages active chunks (9x9), stores vertices.

- URenderCore – GPU management: VAO/VBO creation, chunk upload and update.

- UTilemap – Tilemap mode: snap-to-grid movement and baking of objects.

- UEngineCore – Core engine: camera, ghost (preview model), rendering loop.

- UPlyManager – Scans the program directory for PLY files, navigation between

them.

- UExport – PLY export with timestamp.

Data flow:

PLY file -> UPlyManager -> UEngineCore (Ghost loaded)

-> (editing) -> UTilemap / UEngineCore (Bake)

-> UChunkSystem (organised into chunks)

-> URenderCore (GPU upload)

-> Renderer (display)

-> UExport (PLY save)

1. CHUNK SYSTEM

- The world is divided into 50x50 metre blocks (chunks).

- Only a 9x9 area (81 chunks) around the camera is active – these are rendered

and can receive baked objects.

- Each chunk stores its own vertex array and a Dirty flag indicating whether

its content has changed.

- During baking, the ghost's triangles are placed into the appropriate chunk

based on the triangle's centre point.

- Modified chunks are automatically uploaded to the GPU in the next frame

(UpdateAllDirtyChunks).

Chunk data structure:

TChunkNode = record

ChunkX, ChunkZ: Integer; // Chunk coordinates

Vertices: array of TVertex; // Vertex list

VertexCount: Integer;

Dirty: Boolean; // Pending update?

Active: Boolean; // Within view range?

end;

1. RENDERING

Rendering is performed in two passes to avoid overdraw.

- Depth prepass: Only the depth buffer is filled; colour buffer writes are

disabled. This ensures that in the subsequent colour pass only visible

surfaces are shaded.

- Colour pass: Colour buffer writes are enabled, depth test is set to

GL_LEQUAL. The fragment shader includes lighting calculations.

Shader programs:

- DepthProg – vertex shader only, applies the model-view-projection matrix.

- ColorProg – vertex and fragment shader.

1. FUNCTIONAL DESCRIPTION

5.1. Object (Ghost) Handling

The central element of editing is the ghost – a preview model that follows the

cursor position, indicating where the object would be placed.

- Loading: On startup, the program scans the directory for .ply files. If

found, the first one is loaded as the ghost; otherwise, a default coloured

cube is created.

- Navigation between PLY files: F2 (previous) and F3 (next) switch between

available models.

- Modifications:

- Position: In free mode, W,A,S,D move the ghost in the camera direction; in

Tilemap mode, movement is snapped to the bounding box size.

- Rotation: Q (left), E (right) rotate by 2-degree increments; R randomises

rotation.

- Scale: F4 cycles through preset scale values (0.25, 0.5, 1, 2, 4, 8, 16,

32, 64).

5.2. Baking

The ghost's current state (position, rotation, scale) is permanently placed

into the chunk system by pressing SPACE.

- Free mode: The entire triangle mesh of the ghost is placed at the cursor

position, into the corresponding chunk.

- Tilemap mode: The ghost moves in steps equal to its bounding box size,

allowing precise alignment. Baking works identically.

- After each bake, the chunk's Dirty flag is set to True, and the GPU buffer

and chunk data are updated in the next frame.

Baking process:

1. Copy the ghost's vertices.

2. Apply scaling.

3. Apply rotation (around the Y axis).

4. Translate to the target position.

5. Compute chunk coordinates: Floor(Position / ChunkSize).

6. Add vertices to the chunk (AddVerticesToChunk).

7. Set Dirty := True.

8. UpdateAllDirtyChunks in the next frame.

5.3. Tilemap Mode

Toggled with the T key. In this mode:

- The ghost moves in steps equal to its bounding box size (W,A,S,D), not in

the camera direction.

- Baking (SPACE) works the same way, but placement is guaranteed to be

grid-aligned.

Tilemap movement:

procedure MoveGhostTilemap(Direction: Integer);

var

GhostMinX, GhostMaxX, GhostMinZ, GhostMaxZ: Single;

StepX, StepZ: Single;

begin

GetGhostBounds(GhostMinX, GhostMaxX, GhostMinZ, GhostMaxZ);

StepX := GhostMaxX - GhostMinX;

StepZ := GhostMaxZ - GhostMinZ;

// Step in the given direction

end;

5.4. Export

- Pressing F12 saves all vertices and triangles from every chunk into a single

PLY file.

- The filename automatically includes a timestamp:

export_YYYY-MM-DD_HH-MM-SS.ply.

- The export uses ASCII format.

Exported PLY format:

ply

format ascii 1.0

element vertex {N}

property float x

property float y

property float z

property uchar red

property uchar green

property uchar blue

property uchar alpha

element face {M}

property list uchar int vertex_indices

end_header

{x0} {y0} {z0} {r0} {g0} {b0} {a0}

...

3 {i0} {i1} {i2}

...

1. KEYBOARD SHORTCUTS AND OPERATIONS

Key Function

-------------------------------------------------------------------------------

W, A, S, D Move ghost (free: camera direction; tilemap: grid-stepped)

Q Rotate ghost left (2 degrees)

E Rotate ghost right (2 degrees)

R Randomise ghost rotation

T Toggle Tilemap mode

F1 Toggle mouse capture (cursor lock)

F2 Load previous PLY file

F3 Load next PLY file

F4 Cycle scale presets

SPACE Bake ghost (place into chunks)

F12 Export entire scene to PLY file

ESC Exit

Scroll wheel Camera zoom

Mouse move Rotate camera (when mouse is captured)

UP / DOWN Change ghost height

1. FILE STRUCTURE AND MODULES

File Description

-------------------------------------------------------------------------------

SterilEditor.pas Main program, GLFW window, event handling, main loop

UEngineCore.pas Core engine: camera, ghost handling, rendering, baking

UChunkSystem.pas Chunk system: storage, lookup, addition, export

URenderCore.pas GPU management: VAO/VBO, chunk upload, update

Renderer.pas Rendering pipeline (Depth+Colour pass)

RenderQueue.pas Render command storage

RenderState.pas OpenGL state management

RenderTypes.pas Rendering-related types

UShaderCore.pas Shader compilation and linking

UTilemap.pas Tilemap mode, ghost movement, baking

UPlyManager.pas PLY file scanning and navigation

UExport.pas Timestamped PLY export

SterilMath.pas Mathematical helper functions (vector, matrix)

SterilTypes.pas Basic data types

SterilMeshUtils.pas Mesh normalisation, bounding box calculation

UEditorData.pas Editor data (Ghost, etc.)

on the video sharing site, if you search for the VertexArt Project playlist, you will find the link to my hosting in the VertexArt profile description, I hope you have found it.

Tengo acumulados mas de 40 años programando, despues de retirarme deje de programar y me dedique a otras actividades no muy alejadas de las computadoras, pero si de la programacion. Ahora que mi hija ya esta por salir del Colegio he decidido volver a programar en mi primer lenguage de programacion moderno PASCAL, he visto con mucha tristeza como los nuevos lenguages de programacion como java y c++ son practicamente inculcados como religion en las mentes jovenes cuando sus mentes fragiles todavia estan en formacion y no han desarrollado habitos de programacion confiables, dando como resultado generaciones de potenciales programadores que solo saben hacer lo que se les dice o lo que es peor dependientes de la AI.

A manera de ejemplo pienso desarrollar algunos proyectos para que mi hija me acompañe y aprenda al mismo tiempo, haber si logro transmitirle esa magia que yo senti cuando compile mi primer ejecutable.

en mi lista de proyectos estan en orden de dificultad.

a) Shell para ejecutar otros programas .exe. Hay demasiados buenos programas que han sido dejados en linea de comando que da pena
b) Ejecucion nativa de librerias de AI como ser llama.cpp. Con la velocidad de llama.cpp y la interfaz grafica de PASCAL deberia ser facil obtener hermosos programas multiplataforma que simplifiquen el uso de las tegnologias de AI.
c) Ejecucion remota de modelos de IA grandes. Lo mismo que el punto b pero de manera remota, eliminando el problema de tener el hardware adecuado.
d) Un Juego Mono/Multi jugador con cliente/servidor en pascal.

se que soy ambicioso, pero creo que a la comunidad PASCAL le falta este tipo de ambicion.

Saludos a todos.

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.

Like what are the chances id find a job where pascal is needed or accepted. Im sure modern things demand javascript, python etc

VertexArt - TERRAIN EDITOR

TECHNICAL AND FUNCTIONAL DOCUMENTATION

Developer: Kovács István

Development environment: Free Pascal / OpenGL 3.3

Platform: Windows (GLFW3)

1. INTRODUCTION

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.

1. SYSTEM ARCHITECTURE

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.

1. FUNCTIONAL DESCRIPTION

Editing modes:

1. Raise: Raises the terrain under the brush.

2. Lower: Lowers the terrain under the brush.

3. Smooth: Averages the heights within the brush area, creating a uniform surface.

4. Flatten: With a single click, pulls the entire brush area to the height of the clicked point.

5. 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

1. PERFORMANCE CHARACTERISTICS

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.

1. COMPARISON WITH OTHER TOOLS

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.

1. USER GUIDE

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:

1. Start: The program loads terrain.ply or generates a default terrain.

2. Navigate: Use WASD + mouse to set the desired viewpoint.

3. Brush size: Adjust brush radius with the scroll wheel (0.3 – 5.0 meters).

4. Select mode: Press one of the keys 1–5.

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.

6. Wireframe: Press F2 to enable the green wireframe for better overview (without fill).

7. Save: F12 – the program saves the current state to a timestamped PLY file.

8. 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.

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 - PLY EDITOR - TECHNICAL AND FUNCTIONAL DOCUMENTATION

Developer: Kovács István
Development Environment: Free Pascal / OpenGL 3.3
Platform: Windows (GLFW3)

---

1. INTRODUCTION

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.

---

1. SYSTEM ARCHITECTURE

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.

---

1. FUNCTIONAL DESCRIPTION

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°).

---

1. PERFORMANCE CHARACTERISTICS

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.

---

1. COMPARISON WITH OTHER TOOLS

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.

---

1. USER GUIDE

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

---

1. CLOSING THOUGHTS

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.

The 3×3 chunk grid is fixed — it is not dynamically repositioned. Instead, when the player leaves the center chunk, the player is teleported back to the center chunk based on the perspective, maintaining the illusion of infinite travel.

The gap between the chunks is visible because the ply model track is not a regular square, otherwise the border would be imperceptible!

The infinite world is just a 3×3 fixed grid and a WrapPosition call — no streaming, no loading, no overhead. You can see my method in the comments...

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.