WHAT project I do NOW | script
Every month or day I do task |note
Process | Behind the Work
This page goes beyond the final result. It shows how projects are built — step by step: ideas, structure, problem-solving, and decisions along the way.
Here I keep detailed notes, experiments, and observations —everything that shapes the final outcome.
Instead of finalizing materials in Blender, moved material development into Unreal Engine
🏆Trophy System — Stage 01🏆UE 5.3
Concept & Trophy Generation Foundation🌿
This stage began with a simple task that later became the foundation of the entire system.
The initial requirement was to create a modular trophy setup:
five base trophies, each divided into four parts, so they could be recombined into variations.
No detailed design, style, or visual direction was provided — only a general note:
make it simple, clear, and visually understandable.
Because of that, I had full freedom in defining the concept, style, and visual language.
Concept & Design Approach🌿
Instead of relying on templates, I built everything from scratch.
I had references, but I deliberately didn’t copy them — I worked mostly from intuition.
At that moment, I didn’t feel strong external inspiration, so I made a decision to rely on internal vision instead.
This led to creating original trophy designs that didn’t follow typical patterns.
As a result:
all five trophies were designed from zero
each was split into four interchangeable parts
all elements were built to visually match and combine naturally
The entire set was completed in about one week.
Part of the designs was approved immediately, while some required further iteration.
But overall, the direction proved to be stronger and more original than expected.
Material & Technical Exploration🌿
The trophies were intended to be gold, which introduced a key challenge —
not modeling, but material behavior.
Initially, I experimented with advanced gold materials in Blender:
strong reflections
detailed highlights
physically rich surface response
These versions looked high-end and expressive, but were not approved.
The requirement shifted toward a simpler material.
At this point, I made a technical decision:
Instead of finalizing materials in Blender, moved material development into Unreal Engine,
since the final environment and lighting would exist there.
This significantly improved control and consistency.
Working with Gold — Reflection Problem🌿
The most complex part of this stage was achieving believable gold.
Gold behaves almost like a mirror:
it cannot be too matte (looks cheap)
it cannot be too flat (loses depth)
it depends heavily on environment reflections
Because of this, I had to:
study how Unreal handles reflections and lighting
experiment with different setups
balance roughness, metallic values, and light interaction
After multiple iterations, I achieved a result where:
the trophies look clean and solid when static
but come alive when rotated — catching light and reflecting dynamically
This moment was important — it showed how much the final visual depends not only on the model, but on environment and rendering system.
Form & Light Interaction🌿
Another key design decision was avoiding flat geometry.
For example, the laurel crown elements (inspired by classical Roman trophies):
were not placed in a single plane
each element had slight variation in angle
forms were rotated and offset intentionally
This allowed:
better light catching
richer reflections
more dynamic visual behavior
The same principle applied to the trophies themselves —
they were designed not just as shapes, but as objects interacting with light.
Result of Stage 01🌿
At the end of this stage:
5 original trophies were created
each divided into 4 modular parts
visual style defined from scratch
gold material system established inside Unreal
foundation for procedural generation prepared
What started as a simple modeling task turned into a deeper exploration of:
form
material
light
and system thinking
This became the first building block of the full Trophy System.
The next step expanded this into a complete interactive level.
🏆 Trophy System — Stage 02
Procedural Generator & System Logic
After defining the visual foundation (5 trophies × 4 parts), the project moved into a completely different level — building a generator system. The original idea was simple: create around 58 trophies. But structurally, the design allowed much more. By combining 5 trophies divided into 4 interchangeable parts, the system expanded into: 612 unique variations. This shifted the task from modeling into system thinking.
Challenge & Starting Point
At that moment, I had no prior experience building generators or working with logic systems at this level. As a designer, this was a new type of task — not visual, but structural. Instead of avoiding it, I treated it as a challenge.
I began researching how such systems can be built:
studying Unreal Engine workflows
analyzing procedural logic
exploring node-based systems
combining different approaches
I also worked with AI tools (ChatGPT) to break down possible solutions and test logic structures.
Core System Idea
The solution was built by combining two separate systems into one.
1. Distribution System (Grid / Spawn Logic)
The first system was responsible for:
multiplying objects
placing them in space
generating a grid starting from coordinates (0,0,0)
This allowed creating large-scale layouts of trophies.
2. Variation System (Parts & Randomization)
The second system focused on:
splitting trophies into 4 parts
storing parts inside Arrays
dynamically switching parts
Each trophy:
pulls elements from Arrays
recombines them into a new variation
updates visually during movement
This created a live procedural effect, where trophies change while being interacted with.
System Merge
The key step was combining both systems:
grid spawning (mass creation)
procedural variation (dynamic change)
This resulted in:
large numbers of trophies
each with unique combinations
generated in real time
All triggered by a single action (button press).
Problem — Instability During Movement
At this stage, a critical issue appeared: The trophies were still changing dynamically during movement. For a usable system, they needed to become fixed results, not constantly shifting objects.
Solution — “Sealing” the Result
To solve this, I introduced a “seal” step:
once a trophy is generated → it stops changing
the result becomes stable
each object turns into an instance
This effectively:
locks the variation
preserves uniqueness
allows further use in the system
Instance → Object Conversion
However, another limitation appeared: Instances were not flexible enough for further interaction. To use them inside other systems, they needed to be converted into Blueprint objects.
At this stage:
conversion was done manually
automation would require deeper coding (not implemented yet)
Despite this, the system remained functional and scalable.
System Capability
The final generator allows:
creating hundreds of unique trophies
scaling from small sets to large environments
controlling variation through Arrays
generating results on demand
The number of outcomes is not fixed — it grows depending on how many variations are added to the system.
Result of Stage 02
This stage transformed the project from:
static asset creation
into:
procedural system design
It introduced:
logic thinking
system architecture
dynamic generation
interaction between structure and visual output
And most importantly — it expanded the role from “designer” into designer working with systems.
💎DataTable & Data Workflow
🧾 Trophy System — Stage 03
DataTable & Data Workflow
After building the visual system and the generator logic, the next step shifted into data structure.
Even though the system allowed 612 variations, the task was to define data only for 58 trophies — as a base set.
This introduced a completely different type of work: not visual, not procedural — but data organization.
Task Context
Each trophy required structured information:
name
description
classification / tags
additional parameters
At first, the process seemed simple:
duplicate rows → edit → repeat.
But even at 58 entries, this approach quickly became inefficient. And more importantly — not scalable.
Observation
While working through this manually, I started thinking beyond the task itself.
If even 58 entries take time to maintain, what happens in large-scale productions?
Games like:
World of Warcraft
Hogwarts Legacy..
operate with thousands of entries — constantly updated, refined, and iterated.
At that point, it became clear: manual input is not the real workflow.
Research & Approach
I started exploring DataTable workflows more deeply, using:
Unreal Engine documentation
external resources
AI tools (ChatGPT)
The key discovery was understanding that DataTable is not just a storage — it is part of a data pipeline.
Core Workflow Discovery
The most important realization: Data Tables can be exported and imported between Unreal Engine and external tools.
Unreal → External (Excel / CSV)
extract structured data
organize it more efficiently
edit at scale
External → Unreal
reimport updated data
instantly update the system
This transforms the workflow from manual editing → into controlled data management.
Critical Limitation
During testing, an important constraint became clear: Partial updates are not supported.
When reimporting:
the entire table must be updated
missing fields will reset
incomplete data will overwrite existing structure
This means:
the dataset must always remain complete
consistency is critical
Resulting Approach
Based on this, the workflow became:
Build a complete structured table
Export to external editor (Excel / CSV)
Edit and scale data outside Unreal
Reimport full dataset
Maintain consistency across all fields
Once set up properly:
updates become fast
scaling becomes manageable
iteration becomes safe
Result of Stage 03
This stage introduced:
understanding of data pipelines
structured thinking beyond visuals
efficiency in handling large datasets
awareness of production-level workflows
It also changed how I approach systems:
Not just building visuals or logic — but designing how data flows through them.
Reflection
Even though the task itself was relatively simple, it revealed a foundational layer of development.
What started as “filling rows” became:
→ understanding how systems scale
→ understanding how production actually works
And this is what made this stage valuable.
⚙️ Career Design — Elements Optimize
Memory Optimization & Performance Testing. Optimize memory usage for specific elements — mainly lamps and animated butterflies. At first, this was unexpected. These elements had already been tested before and did not affect performance.
So the first step was not optimization — but verification.
Initial Hypothesis
Two possible sources of load:
dynamic light (Unreal light components)
animated assets (butterflies with loop animation)
Additionally, I already had an idea for an alternative lamp:
→ replacing real light with a material-based fake glow. This could reduce cost if lighting became an issue.
Alternative Solution (Lamp)
I designed a second version of the lamp:
no real light component
emissive material simulating glow
subtle animated effect (rotation / movement inside material)
Because the scene is mostly viewed from top-down, this fake approach works visually without loss of quality.
Visual Adjustment
While rebuilding the lamp, I also noticed a visual issue:
the original lamp stretched incorrectly in perspective
it looked too long from certain angles.
So I adjusted the proportions:
compressed the lamp vertically
optimized it for multi-angle viewing
Result:
→ visually more stable
→ even cleaner than the original version
Testing Process
I created a controlled test scene and checked performance step by step:
Butterflies
1 instance → no load
3 instances → no load
10 instances → still stable
Reason:
low poly
single loop animation
optimized material
✔ Result: butterflies are not the issue
Lamps (New Version)
emissive material only
multiple instances tested
✔ Result: no performance impact
Lamps (Original Unreal Light)
tested with real light sources
combined with scene elements
✔ Result: still no critical load
Combined Test
butterflies + lamps + environment
camera movement
interaction simulation
Observed:
minor spikes during loading
But:
→ these were one-time events
→ likely shader compilation or system-level loading
✔ Not related to assets themselves
Final Conclusion
The tested elements:
butterflies
lamps (both versions)do not create performance issues
* Frame time was stable (approximately 16-20ms)
* No sustained performance degradation was observed
* Spikes were temporary and are thought to be due to shader or texture streaming
* Increasing the number of butterflies and lamps did not result in an increase in load.
The source of memory load is located elsewhere in the project.
Result of Stage 04
verified asset performance through controlled testing
designed an optimized fallback solution (fake lamp)
improved visual quality while optimizing structure
isolated the problem from my part of the system
Reflection
This stage was not about “fixing a problem” —
but about proving where the problem is not.
And that is equally important in production.
Instead of blindly optimizing:
tested assumptions
validated behavior
separated responsibility
Optimization is not always about changing — sometimes it is about understanding.
2026 三TH三R
ANGELINA Popova