Pinned Tweet
Building mesh nodes:
- Generators + topology ops (cut, weld, triangulate, extrude, blast)
- BVH / KD-tree / Octree with polygon raycast
- Provenance: attributes survive topology changes, no remap code
- Node editor on #Unity Graph Toolkit, pull-cook + push-dirty
- Custom C# nodes
I keep working on my electrical circuit simulator. I finally finished the black boxes: you can hide some of the elements inside them, or place components right on the box's board and use it as a mounting board.
Viktor Grigorev retweeted
FLUX 3 Image Klein is here.
Open Weights with the quality of a large frontier model. Customizable and fast.
5.6B parameters and runs on a single consumer GPU.
Native 4K, bounding boxes, and pixel-perfect editing.
Just finished black boxes in my circuit simulator. Now you can build a custom device or investigate black boxes built by others.
Wow!
teapawt.net/mizuki_izuna/status/21…
CAPCOM’s next-gen RE ENGINE work is very interesting.
They’re basically attacking several pain points at once: C++ complexity, long build/link times, memory corruption and leaks, awkward reflection, duplicated C++/C# type systems, expensive marshaling, IL2CPP debugging, GC pressure, and memory fragmentation.
The answer seems to be RE:Runtime + RE:C++.
RE:C++ is built around C++23, but with C#-like semantics layered on top: automatic memory management, generics, interfaces, boxing, exceptions, and access to the .NET standard library.
The really interesting part is the workflow.
CAPCOM is using C# as the frontend language for parts of the runtime. Code is written in C#, compiled into a normal .NET assembly, then RE:Build converts/decompiles that into RE:C++ and builds it into native libraries/executables.
So the rough pipeline is:
C# → .NET DLL → RE:C++ → native C++ binary
That means developers can work with C# syntax, tooling, libraries, reflection, attributes and unit testing, while the final game/runtime code still ends up native.
They’re also doing their own memory-management work underneath this. Instances are managed in 64 KB pages, with page reference counting plus cache and GC optimizations. The goal seems to be reducing the cost of managing huge numbers of objects while improving locality and avoiding some of the fragmentation problems they’ve had before.
This also makes CAPCOM’s REDox project much more interesting.
REDox is their open-source .NET serialization/data library, with JSON, CBOR, MessagePack-style structured data handling, lazy decoding, streaming, compact token storage, etc.
At first glance it just looks like a standalone .NET library.
In context, it looks much more like the kind of infrastructure they can write and test normally in C#, then feed into this RE:Runtime / RE:C++ pipeline and ship as native engine code.
#RE2026CAPCOM #CAPCOM
Viktor Grigorev retweeted
teapawt.net/mizuki_izuna/status/21…
CAPCOM’s next-gen RE ENGINE work is very interesting.
They’re basically attacking several pain points at once: C++ complexity, long build/link times, memory corruption and leaks, awkward reflection, duplicated C++/C# type systems, expensive marshaling, IL2CPP debugging, GC pressure, and memory fragmentation.
The answer seems to be RE:Runtime + RE:C++.
RE:C++ is built around C++23, but with C#-like semantics layered on top: automatic memory management, generics, interfaces, boxing, exceptions, and access to the .NET standard library.
The really interesting part is the workflow.
CAPCOM is using C# as the frontend language for parts of the runtime. Code is written in C#, compiled into a normal .NET assembly, then RE:Build converts/decompiles that into RE:C++ and builds it into native libraries/executables.
So the rough pipeline is:
C# → .NET DLL → RE:C++ → native C++ binary
That means developers can work with C# syntax, tooling, libraries, reflection, attributes and unit testing, while the final game/runtime code still ends up native.
They’re also doing their own memory-management work underneath this. Instances are managed in 64 KB pages, with page reference counting plus cache and GC optimizations. The goal seems to be reducing the cost of managing huge numbers of objects while improving locality and avoiding some of the fragmentation problems they’ve had before.
This also makes CAPCOM’s REDox project much more interesting.
REDox is their open-source .NET serialization/data library, with JSON, CBOR, MessagePack-style structured data handling, lazy decoding, streaming, compact token storage, etc.
At first glance it just looks like a standalone .NET library.
In context, it looks much more like the kind of infrastructure they can write and test normally in C#, then feed into this RE:Runtime / RE:C++ pipeline and ship as native engine code.
#RE2026CAPCOM #CAPCOM
Today is my birthday 🎉 and this is my present for you.
I've published my first addon for #godot. It's a fork of BetterTerrain but with steroids.
- Organize and filter all your terrains and tiles
- Quickly create autotiled terrains with cliffs/walls
- Simple tiling, object sets (ideal for trees), and scatter sets
- Slopes & complex structures ...and many more And upcoming new tools:
- Easier collision editing & set
- Faster animated tile creation
See 🧵 for more info:
#indiedev #gamedev
Viktor Grigorev retweeted
After 6.5 years, I’ve decided to leave Unity, and hope I have helped you make great games!
It’s been brilliant to have the opportunity to serve the video game developer community, and make a lot of friends.
More details here: linkedin.com/posts/laurentgi…
Viktor Grigorev retweeted
This is a really elegant implementation. We've had something conceptually very similar for a long time, but this topology is much cleaner than ours. Nice work!
PropellerheadViJ spent weeks rebuilding their mesh boolean system in Unity from scratch after the first approach kept breaking down at scale. Here's a quick look at it. 🔧
See the details: reddit.com/r/Unity3D/comment…
#unity3d #gamedev
Viktor Grigorev retweeted
PropellerheadViJ spent weeks rebuilding their mesh boolean system in Unity from scratch after the first approach kept breaking down at scale. Here's a quick look at it. 🔧
See the details: reddit.com/r/Unity3D/comment…
#unity3d #gamedev
Viktor Grigorev retweeted
AutoRemesher 1.0 is released.
An automatic quad remeshing tool — now MIT licensed.
I reimplemented MIT-incompatible deps so this can be used freely in commercial projects.
github.com/huxingyi/autoreme…
#autoremesher #retopology #opensource #gamedev
Great to see such improvements! Looks like 6.7 LTS will be the most polished version this year
「Unity 6.5」最新アップデートの解説動画✨
2D機能強化、Shader Graph更新、エディター/ワークフロー改善、Android/iOS向け性能改善、Built-Inパイプライン非推奨化まで、注目ポイントをまとめてチェック👇
▼動画はこちら
urls.unity3d.jp/4eYnJ0d
#Unity #Unity6
Viktor Grigorev retweeted
Atari and MobyGames launch new career development platform called Moby Professional gamedeveloper.com/business/a…
I hope it works as good as it looks like. I have an old idea I want to implement, and I need segmentation for it
Tripo Segmentation now breaks 3D models into meaningful parts based on their geometry.
Get cleaner boundaries, more accurate part separation, and fewer manual fixes when you need production-ready results.
Choose from Simple, Balanced, or Detailed to match your workflow.
Perfect for 3D printing, game assets, and downstream editing.
Tripo Segmentation now breaks 3D models into meaningful parts based on their geometry.
Get cleaner boundaries, more accurate part separation, and fewer manual fixes when you need production-ready results.
Choose from Simple, Balanced, or Detailed to match your workflow.
Perfect for 3D printing, game assets, and downstream editing.
Implemented exact boolean ops on meshes in #Unity for my node editor - ran them through the Solidean reference tests: sequential sweep cuts, cubes built up and cut back down via Union and subtraction. That was a hard week.
Viktor Grigorev retweeted
UnityCsReference が更新されました 😭
6000.6.0a7 までカバー
github.com/Unity-Technologie…





















