Building a Penetration-Free Cloth Simulation Component in Unity
During my internship at Core Engage, I wanted to work on something that was close to game development but still technically challenging. Instead of building a small complete game in 30 working days, I chose to focus on a deeper game component: a cloth simulation system based on a recent contact handling method called Offset Geometric Contact.
The goal was to take an advanced computer graphics paper and turn its ideas into a working Unity prototype. This made the project a mix of research, physics simulation, optimization, and practical game-engine development.
Starting Point
The project began with a simple question: how can I create cloth objects in Unity and control their movement at the vertex level?
Before thinking about collision handling, I needed a cloth mesh that I fully controlled. I started by generating grid meshes procedurally, so the resolution, vertex positions, triangle indices, and topology were all created through code. This gave me a clean base for testing physics behavior.
At this stage, the system was not really “cloth” yet. It was just a dynamic mesh made of particles. The next step was making those particles move in a physically believable way.
Moving From Meshes to Simulation
To move the cloth vertices, I first studied Verlet Integration and position-based simulation methods. Instead of treating the system only through forces, Position Based Dynamics focuses on directly adjusting particle positions until constraints are satisfied. This approach is common in real-time graphics because it is easier to control, stable, and practical for interactive applications.
I implemented the early solver structure around this idea, then moved toward XPBD because it improves one of the important weaknesses of traditional PBD: stiffness changing depending on timestep and solver iteration count. For a cloth system, this matters because stretch, bend, shear, and similar constraints should remain controllable as the simulation settings change.
After implementing the XPBD solver, I added the main cloth constraints one by one:
- Stretch constraints to keep neighboring particles from moving too far apart
- Bend constraints to control folding behavior
- Shear constraints to support diagonal deformation
- Area and strain-related constraints to improve cloth-like motion
At this point, the system could generate cloth meshes and simulate cloth-like movement under gravity.
Why Offset Geometric Contact?
The main research part of the project was adapting Offset Geometric Contact, or OGC, into this Unity simulation.
The problem OGC tries to solve is penetration-free contact. In cloth simulation, surfaces can easily pass through each other, especially during self-collision or tight contact. Once that happens, the simulation can produce visible artifacts or become difficult to recover.
OGC approaches this by using a geometric contact model and displacement bounds that prevent vertices from moving into invalid positions. The original method is designed with efficient parallel execution in mind, especially for GPU-based simulation. My version was a smaller CPU-based Unity prototype, so I had to adapt the idea to a simpler environment.
I divided the OGC part into three main pieces:
-
Contact detection Finding vertex/facet and edge/edge pairs that are close enough to interact.
-
Trust region generation Calculating movement limits so particles do not move beyond a safe region during a simulation step.
-
Contact solving Applying a contact response inside the XPBD-based solver structure.
This breakdown helped me turn the paper into smaller implementation problems instead of trying to understand the whole method at once.
Contact Detection and Performance
The first major challenge was contact detection.
A naive approach would compare every vertex and edge against every other possible contact candidate. That quickly becomes too expensive as the cloth resolution increases. Even small cloth meshes can contain many vertices, edges, and triangles, so the number of checks grows very fast.
To solve this, I implemented Bounding Volume Hierarchy structures for triangles and edges. The idea was to group nearby geometry into bounding boxes, then only test candidates that are likely to be close enough to matter.
This part of the project helped me understand how much simulation work depends on acceleration structures. The collision algorithm itself is important, but without a way to reduce unnecessary checks, the system cannot scale.
Adapting the Solver
The original OGC paper uses a solver direction that is more suitable for parallel execution. In my case, implementing that full solver would have made the project too large for the internship timeframe, so I adapted the contact handling idea into my XPBD-based system instead.
This was one of the most useful parts of the project for me. I had to compare the paper’s ideal implementation with what was realistic in my own prototype. That meant understanding not just what the paper does, but why it does it, what parts are essential, and what parts can be simplified for a smaller Unity implementation.
By the end of the project, I had a CPU-based Unity component that could generate cloth meshes, simulate cloth behavior with XPBD constraints, detect close contacts, and apply a penetration-prevention approach inspired by OGC.
Results and Limitations
The final prototype produced examples of cloth surfaces interacting without obvious penetration in the tested scenes. It was not a full production-ready cloth simulator, but it reached the main goal of the internship project: adapting a recent computer graphics technique into a working Unity component.
The biggest limitation was performance. As the number of vertices increased, the simulation became significantly more expensive. The BVH system helped reduce the cost of contact detection, but the project still showed clearly why the original OGC method focuses on parallel GPU execution.
A natural next step would be moving more of the algorithm to the GPU with compute shaders. This would make the project a good continuation point for learning GPU programming, parallel simulation, and more advanced real-time graphics techniques.
What I Learned
This project helped me grow in a few different ways.
Technically, I learned more about procedural mesh generation, cloth constraints, XPBD solvers, contact detection, BVH optimization, and research-paper implementation. More importantly, I learned how to approach a difficult graphics problem by breaking it into smaller systems and building a prototype step by step.
It also gave me a better understanding of how academic graphics techniques can be transformed into game-engine components. Reading the papers was only one part of the process; the real challenge was deciding how to simplify, implement, test, and iterate inside Unity.
For me, this project became more than an internship task. It was a focused exploration of the kind of technical game development work I want to keep improving at: visual systems, real-time simulation, and interactive computer graphics.
Unity’de Penetrasyonsuz Bir Kumaş Simülasyonu Bileşeni Geliştirmek
Core Engage’deki stajım sırasında, oyun geliştirmeye yakın ancak teknik açıdan daha zorlayıcı bir proje üzerinde çalışmak istedim. Otuz iş günü içinde küçük ve tamamlanmış bir oyun geliştirmek yerine, daha derin bir oyun bileşenine odaklandım. Üzerinde çalıştığım proje, Offset Geometric Contact adı verilen güncel bir temas yöntemini temel alan kumaş simülasyonu sistemi oldu.
Amacım, ileri seviye bir bilgisayar grafiği makalesindeki fikirleri çalışan bir Unity prototipine dönüştürmekti. Bu hedefle araştırma, fizik simülasyonu, optimizasyon ve oyun motoruna adaptasyonu bir araya getiren güzel bir çalışmayı tamamladım.
Başlangıç Noktası
Projenin ilk adımı Unity’de özel kumaş nesneleri oluşturmayı, ve bu nesnelere doğal kumaş hareketleri kazandırmayı öğrenmek ve uygulamak oldu.
Çarpışma yönetimini düşünmeden önce tamamen kontrol edebildiğim bir kumaş mesh’ine ihtiyacım vardı. Bu nedenle projeye, grid tabanlı mesh’leri prosedürel olarak oluşturarak başladım. Çözünürlük, köşe konumları, üçgen indeksleri ve topoloji kod aracılığıyla üretiliyordu. Bu yapı, fizik davranışlarını test edebilmek için temiz bir temel sağladı.
Bu aşamada sistem henüz gerçek anlamda bir “kumaş” değildi. Yalnızca parçacıklardan oluşan dinamik bir mesh’ti. Bir sonraki adım, bu parçacıkların fiziksel olarak inandırıcı biçimde hareket etmesini sağlamaktı.
Mesh Yapısından Simülasyona Geçiş
Kumaşın köşe noktalarını hareket ettirmek için önce Verlet Entegrasyonu ve konum tabanlı simülasyon yöntemlerini inceledim. Bu süreçte, sistemi yalnızca kuvvetler üzerinden çözmek yerine kısıtlamalar sağlanana kadar parçacık konumlarını doğrudan düzeltmeye odaklanan Position Based Dynamics yöntemini öğrendim. Kontrol edilmesi daha kolay, kararlı ve etkileşimli uygulamalara uygun olduğu için bu yaklaşımın gerçek zamanlı grafiklerde sıkça kullanıldığını.
İlk çözücü yapısını bu fikir etrafında geliştirdikten sonra XPBD yöntemine geçtim. Bu süreçte XPBD’nin, geleneksel PBD’nin önemli zayıflıklarından biri olan sertlik değerlerinin zaman adımına ve çözücü yineleme sayısına bağlı değişmesini azalttığını öğrendim. Bunun, esneme, bükülme ve kayma gibi kısıtlamaların farklı simülasyon ayarlarında da daha tutarlı ve kontrol edilebilir kalmasını sağladığını gördüm.
XPBD çözücüsünü geliştirirken temel kumaş kısıtlamalarını tek tek ekledim:
- Komşu parçacıkların birbirinden fazla uzaklaşmasını engelleyen esneme kısıtlamaları
- Katlanma davranışını kontrol eden bükülme kısıtlamaları
- Çapraz deformasyonu destekleyen kayma kısıtlamaları
- Kumaşa benzer hareketi iyileştiren alan ve gerinim tabanlı kısıtlamalar
Bu aşamada sistem, kumaş mesh’leri oluşturabiliyor ve yerçekimi altında kumaşa benzer hareketleri simüle edebiliyordu.
Neden Offset Geometric Contact?
Projenin temel araştırma kısmı, Offset Geometric Contact, yani OGC yöntemini Unity tabanlı simülasyona uyarlamaktı.
OGC’nin çözmeye çalıştığı temel problem penetrasyonsuz temastır. Kumaş simülasyonlarında yüzeyler, özellikle öz çarpışmalarda veya sıkı temas durumlarında kolayca birbirinin içinden geçebilir. Bu gerçekleştiğinde simülasyonda görünür hatalar oluşabilir ve sistemin geçerli duruma geri dönmesi zorlaşabilir.
OGC, köşe noktalarının geçersiz konumlara hareket etmesini engelleyen geometrik bir temas modeli ve yer değiştirme sınırları kullanır. Orijinal yöntem, özellikle GPU tabanlı simülasyonlarda verimli paralel çalıştırmaya uygun şekilde tasarlanmıştır. Benim geliştirdiğim sürüm ise daha küçük, CPU tabanlı bir Unity prototipiydi. Bu nedenle yöntemi daha sade bir çalışma ortamına uyarlamam gerekti.
OGC bölümünü üç ana parçaya ayırdım:
-
Temas tespiti Etkileşime girecek kadar birbirine yaklaşan köşe-yüzey ve kenar-kenar çiftlerinin belirlenmesi.
-
Güven bölgesi oluşturma Parçacıkların bir simülasyon adımı sırasında güvenli bölgenin dışına çıkmasını engelleyen hareket sınırlarının hesaplanması.
-
Temas çözümü Temas tepkisinin XPBD tabanlı çözücü yapısı içinde uygulanması.
Bu ayrım, makalenin tamamını tek seferde anlamaya çalışmak yerine yöntemi daha küçük uygulama problemlerine dönüştürmeme yardımcı oldu.
Temas Tespiti ve Performans
Karşılaştığım ilk büyük zorluk temas tespitiydi.
İlk test ettiğim yaklaşımda her köşe ve kenar, diğer tüm olası temas adaylarıyla karşılaştırılıyordu. Ancak kumaş çözünürlüğü arttıkça bu yöntem hızla çok maliyetli hale geliyordu. Küçük kumaş mesh’leri bile çok sayıda köşe, kenar ve üçgen içerebildiğinden, yapılması gereken kontrol sayısı kısa sürede büyük ölçüde artıyordu.
Bu sorunu çözmek için üçgenler ve kenarlar için Bounding Volume Hierarchy yapıları geliştirdim. Temel fikir, birbirine yakın geometrileri sınırlayıcı kutular içinde gruplandırmak ve yalnızca gerçekten yakın olma ihtimali bulunan adayları test etmekti.
Projenin bu bölümü, simülasyon çalışmalarının ne kadar büyük ölçüde hızlandırma yapılarına bağlı olduğunu anlamamı sağladı. Çarpışma algoritmasının kendisi önemli olsa da gereksiz kontrolleri azaltacak bir sistem olmadan ölçeklenebilir bir çözüm oluşturmanın pek mümkün olmadığını gördüm.
XPBD Çözücüsünü OGC’ye Uyarlamak
Orijinal OGC makalesi, paralel çalıştırmaya daha uygun bir çözücü yaklaşımı kullanıyordu. Benim projemde bu çözücünün tamamını uygulamak, staj süresi için projenin kapsamını gereğinden fazla büyütecekti. Bu nedenle temas yönetimi fikrini kendi XPBD tabanlı sistemime uyarladım.
Bu süreç, projenin benim için en faydalı bölümlerinden biri oldu. Makaledeki ideal uygulamayla kendi prototipimde gerçekçi olarak yapabileceklerimi karşılaştırmam gerekti. Bu da yalnızca makalenin ne yaptığını değil; bunu neden yaptığını, hangi bölümlerin temel olduğunu ve hangilerinin daha küçük bir Unity uygulaması için sadeleştirilebileceğini anlamamı gerektirdi.
Projenin sonunda kumaş mesh’leri oluşturabilen, XPBD kısıtlamalarıyla kumaş davranışını simüle edebilen, yakın temasları tespit edebilen ve OGC’den esinlenen bir penetrasyon önleme yaklaşımı uygulayan CPU tabanlı bir Unity bileşeni geliştirdim.
Sonuçlar ve Sınırlamalar
Nihai prototip, test edilen sahnelerde belirgin bir penetrasyon oluşmadan etkileşime giren kumaş yüzeyleri üretebildi. Tam kapsamlı ve üretime hazır bir kumaş simülatörü değildi ancak staj projesinin temel hedefi olan “güncel bir bilgisayar grafikleri yöntemini çalışan bir Unity bileşenine uyarlamak” amacına başarıyla ulaştı.
En büyük sınırlama performanstı. Köşe noktası sayısı arttıkça simülasyonun işlem maliyeti de belirgin şekilde yükseliyordu. BVH sistemi temas tespitinin maliyetini azaltmaya yardımcı olsa da proje, orijinal OGC yönteminin neden paralel GPU çalıştırmasına odaklandığını açıkça gösterdi.
Projenin doğal bir sonraki adımı, algoritmanın daha büyük bir bölümünü compute shader’lar aracılığıyla GPU’ya taşımak olabilir. Bu yaklaşım projeyi GPU programlama, paralel simülasyon ve daha ileri gerçek zamanlı grafik tekniklerini öğrenmek için uygun bir devam çalışmasına dönüştürebilir.
Öğrendiklerim
Bu proje, farklı alanlarda gelişmeme yardımcı oldu.
Teknik açıdan prosedürel mesh üretimi, kumaş kısıtlamaları, XPBD çözücüleri, temas tespiti, BVH optimizasyonu ve akademik makalelerin uygulanması hakkında daha fazla deneyim kazandım. Daha önemlisi, zor bir grafik problemini küçük sistemlere ayırarak ve adım adım prototip geliştirerek nasıl ele alabileceğimi öğrendim.
Aynı zamanda akademik grafik tekniklerinin oyun motoru bileşenlerine nasıl dönüştürülebileceğini daha iyi anlamamı sağladı. Makaleleri okumak sürecin yalnızca bir parçasıydı. Asıl zorluk, yöntemin Unity içinde nasıl sadeleştirileceğine, uygulanacağına, test edileceğine ve tekrar geliştirileceğine karar vermekti.
Bu proje benim için yalnızca bir staj görevi olmaktan çıkarak, üzerinde gelişmeye devam etmek istediğim teknik oyun geliştirme alanlarına odaklanan bir çalışma hâline geldi.