Dust3D awarded Epic MegaGrants

I am very excited to share that Dust3D has been awarded Epic MegaGrants.

Dust3D is a 3D modeling software for quick making game assets with texture and rig automatically generated, it supports Linux, MacOS, and Windows. And it’s fully opensourced since the first day, https://github.com/huxingyi/dust3d

Epic MegaGrants is a funding provided by Epic Games,

to support game developers, enterprise professionals, media and entertainment creators, students, educators, and tool developers doing amazing things with Unreal Engine or enhancing open-source capabilities for the 3D graphics community. https://www.unrealengine.com/en-US/megagrants

Thank you Epic Games and all the contributors,

Siaržuk Piatroŭski  
Alistair Miles  
Ian Diaz  
David Patrick  
Abraão Filho  
John Tsiombikas  
Jared Deckard  
Brandon Vandegrift  
Jimmy Gunawan  
Ruben Niculcea  
Toshio Araki  
Evan Gruda  
Kubilay Yalçın  
Satish Goda  
Sawm Fawk  
Erlend Sogge Heggen  
Michael Nowak  

* Ordered by first contribution

there are many others who also give invaluable supports not listed, thank you all, the grant will enable more possibilities for this tiny software.

Please stay tuned by join our mailing list and twitter hash tag #10minuteseveryday!

Dust3D on Raspberry Pi 3 Model B+

My friend Kevin Liang, who helped me 3D printed many cool Dust3D models, bought a Raspberry Pi 3 Model B+, the first thing to do when he received this tiny size computer is to run Dust3D, the same tiny size 3D modeling software.

Unfortunately, the Travis CI generated AppImage file can not run on Pi’s ARM CPU. But we can always build from source.

Most of the needed dev tools are out of the box on the default system, such as gcc, make. The Dust3D build instructions which written for Ubuntu, works like a charm on Pi. However, it always failed on the same file nodemesh/combiner.cpp, this file used CGAL library heavily. Every time, the machine dies on compiling this file, all system lose response. After power off, try, die, power off again, try, die again, several times, we found, out of memory is the root cause.

Googling keywords, “gcc low memory”, the first answer by Colin lan King shows how to create large swap memory for linux. So we created 4G swap for Pi to replace the default 100M swap.

Finally, more than one hours building, we succeed running Dust3D on Raspberry Pi.

The following are the full commands to build Dust3D on a Raspberry Pi 3 Model B+ with default system.

; Prepare 4G virtual memory for building, the default 1G memory and 100M swap are not enough to build.
; (The following swap image creating script comes from Colin lan King)

$ dd if=/dev/zero of=swap.img bs=1M count=4096
$ mkswap swap.img
$ chmod 0600 swap.img
$ sudo chown root:root swap.img
$ swapon swap.img

; Install dependencies

$ sudo apt-get install qtbase5-dev
$ sudo apt-get install qttools5-dev-tools
$ sudo apt-get install libcgal-dev
$ sudo apt install cmake
$ wget https://github.com/CGAL/cgal/releases/download/releases/CGAL-4.13/CGAL-4.13.zip
$ unzip CGAL-4.13.zip
$ cd CGAL-4.13
$ mkdir build
$ cd build
$ cmake ../
$ make
$ sudo make install

; Build Dust3D

$ git clone https://github.com/huxingyi/dust3d.git
$ cd dust3d
$ qmake -qt=5 -makefile
$ make

; Run Dust3D

$ ./dust3d

Dust3D 1.0 Beta 17 Is Now Available

Dust3D 1.0.0-beta.17 is now available, here are the changes,

  • Remote IO Protocol
  • Uncombined Mode
  • User Defined Cut Face
  • Base Plane Constrain
  • Color Solubility
  • Crash Fix


Remote IO Protocol:

This is an experiment with Evan from University of Florida, to enable third party software/hardware to control the modeling process of Dust3D. This feature remains in experiment stage and may not exist in the final 1.0 stable version. See the protocol here: http://docs.dust3d.org/en/latest/remote_io_protocol.html

Uncombined Mode:

There are Normal and Inverse modes there before this release for component, normal represents the normal mesh union, inverse represents the mesh subtraction. This release introduce Uncombined mode, which represents the component would not take part in the mesh boolean algorithms. Be noticed that, model with uncombined mode component exists, would not be generate as a watertight mesh.

User Defined Cut Face:

Cut face is the extruding shape, with this release, the cut face could be configured as Quad, Pentagon, Hexagon, Triangle, and User Defined. User defined cut face could be selected from other parts with the target set to Cut Face. See demo here: https://twitter.com/jeremyhu2016/status/1132026219522772993

Base Plane Constrain:

Mesh layout and thickness adjustment are depend on base plane calculation. This release introduce the constrain settings: Dynamic, Side Plane, Front Plane, and Top Plane. It’s useful to limit the directions of mesh been generated. See demo here: https://twitter.com/jeremyhu2016/status/1130586879454109696

Color Solubility:

If one part configured color solubility, the generated color texture seam between the neighbor parts will be gradient filled using this part’s color with the specified solubility. See demo here: https://twitter.com/jeremyhu2016/status/1132159910815227904

P.S. Please note that, there is a #10minuteseveryday activity on going, where there are some fresh daily models been added.

First time ever! Dust3D model get 3D printed

I’ve always wanted to try 3D printing, today I finally get my hands on it! Cos my day job company has bought a MakerBot. :)

It took the printer 30min to print this frog, from nothing to real thing! I was super stoked.

(Lowpoly frog, 3D Printing in MakerBot, model generated by Dust3D)

Though it’s not my intention, it’s not a coincidence that models made in Dust3D is perfectly suitable for 3D print, the reason being so is that Dust3D models are watertight and no self intersection.

I remember the first ever model made in Dust3D by myself was an ant. I showed it to my day job manager, after that he refers my software as “Jeremy’s Bug Application”, is ant a bug? LOL. I kind of like the name. The feeling of knowing the software which I wrote from scratch can actually work and generate 3D models properly, was ever so sweet.

Today this feeling had come back to me.

Why I rewrote the mesh generator of Dust3D from Rust to C++

Dust3D is a quick 3D modeling software. It automatically generates a mesh from nodes drawn by the user. Most of the code is implemented in C++ with Qt, including the UV unwrapper, rigger, pose and motion editor etc, however, the core mesh algorithm was written in Rust. Recently I have rewritten the Rust part. The codebase is pure C++ now.

(Screenshot of Dust3D, the three thumbnails in the lower right corner are the preview of exported result in Godot, Unity, and Blender)

I have been asked if I am going to migrate more of the C++ code in Dust3D to Rust, and there is another author who has contributed many excellent improvements on the Rust code, thanks anderejd. I think I’d better explain a little bit why I dropped the Rust implementation from Dust3D.

The mesh generator was originally implemented in pure C, then migrated to Rust. Why did I switch to Rust? C is quite lacking in infrastructure, but I was sick of different C++ trivial variations across different platforms, it’s a pain to introduce a third party library if you want your whole code to work on different systems with different versions and brands of compiler. Rust has all the merits I wanted, it’s easy to start, painless to include other libraries, and most importantly, it’s memory safe. If you have ever been heart attacked by core dumps, you will know how beautiful this is.

Given so many advantages, why I am switching back to C++? The most beautiful thing about Rust is also a disadvantage. When you implement an algorithm using C++, you can write it down without one second of pause, but you can’t do that in Rust. As the compiler will stop you from borrow checking or something unsafe again and again, you are being distracted constantly by focusing on the language itself instead of the problem you are solving. I know the friction is greater because I am still a Rust learner, not a veteran, but I think this experience stops a lot of new comers, speaking as someone who already conquered the uncomfortable syntax of Rust, coming from a C/C++ background.

Another reason is the Rust ecosystem is still immature. As an indie game developer I can see the situation is changing, there is a website Are we game yet? that lists many neat things in the Rust world, there is a data driven game engine written in Rust called Amethyst, all these things look really promising. But, there is no Qt, no CGAL etc, all these frameworks and libraries have been developed for so many years and maintained very high level of quality. I know there are some bindings, but it’s not mature and not enough.