open-source 3D painting tool ArmorPaint
http://www.cgchannel.com/2020/01/check-out-open-source-3d-painting-tool-armorpaint
ArmorPaint - open source
- Thread starter erikals
- Start date
open-source 3D painting tool ArmorPaint
http://www.cgchannel.com/2020/01/check-out-open-source-3d-painting-tool-armorpaint
jwiede
Electron wrangler
That looks cool!
What it doesn't look like is a "Feature Request". :devil:
jwiede
Electron wrangler
Did you notice it's mostly written in/for Haxe?
Taking a decent-sized body of code written for a high-level cross-platform language/environment like Haxe, and integrating it into an native-code application which consists mostly of C and some C++ requires a very substantial amount of effort, both in design/planning and in implementation.
Think of it this way: The simple LOGO app "REPEAT 4 [ FD 10 RT 90 ]" is a _tiny_ bit of code, and took a second or two to plan and implement. However, migrating the same app to C/C++ would require vastly more planning to replicate, both in planning (figuring out 2D gfx libraries, dealing with platform IO & gfx concerns, etc.) and in implementation (simply because it would take many, many more lines of code to replicate in C/C++).
The problem moving from a high-level language and environment to a platform-specific low-level language is that first you need to figure out how to replicate all the environmental services and abstractions by the high-level code such that equivalents are available (where possible) for your low-level language coding. Then, not only do you have to implement low-level code to produce the same results, but also to replace any high-level environment services you weren't able to easily replicate (or for cases where the high-level service doesn't "mesh well" with your platform).
It's not that it's impossible, but it's a HECK of a lot more work than integrating the same app if it were written in C/C++ for Windows or similar -- that would actually make the job much easier, mostly because it's at the "same linguistic level", and dealing with the same environmental services/abstractions as LW itself (and they understand how to map those to Mac, etc.).
Taking a decent-sized body of code written for a high-level cross-platform language/environment like Haxe, and integrating it into an native-code application which consists mostly of C and some C++ requires a very substantial amount of effort, both in design/planning and in implementation.
Think of it this way: The simple LOGO app "REPEAT 4 [ FD 10 RT 90 ]" is a _tiny_ bit of code, and took a second or two to plan and implement. However, migrating the same app to C/C++ would require vastly more planning to replicate, both in planning (figuring out 2D gfx libraries, dealing with platform IO & gfx concerns, etc.) and in implementation (simply because it would take many, many more lines of code to replicate in C/C++).
The problem moving from a high-level language and environment to a platform-specific low-level language is that first you need to figure out how to replicate all the environmental services and abstractions by the high-level code such that equivalents are available (where possible) for your low-level language coding. Then, not only do you have to implement low-level code to produce the same results, but also to replace any high-level environment services you weren't able to easily replicate (or for cases where the high-level service doesn't "mesh well" with your platform).
It's not that it's impossible, but it's a HECK of a lot more work than integrating the same app if it were written in C/C++ for Windows or similar -- that would actually make the job much easier, mostly because it's at the "same linguistic level", and dealing with the same environmental services/abstractions as LW itself (and they understand how to map those to Mac, etc.).
Last edited:
jwiede
Electron wrangler
Just for completeness, there's another big issue I feel obliged to mention:
You also definitely need someone very practically familiar with both Haxe, the application, and C/C++ to help with the migration.
Why?
Because as a working Haxe application, there is undoubtedly idiosyncratic code present in order to produce (or avoid) issues with the Haxe language/environment. It's vitally important that those idiosyncratic code sections are noted and the resultant idiosyncratic behavior is well-understood.
Someone who just knows the language/environment "by book" won't easily be able to identify such idiosyncratic code "in the wild". As a result, they'll instead use a "literal translation" when migrating those areas, resulting in behavior different from the original application's behavior -- or, put better, it means they just introduced defects. Worse, if they don't understand the original app's behavior really well in the first place, chances are they'll also have difficulty identifying that their code's behavior difference is the cause of the problems (or even that there is a difference in behavior).
You also definitely need someone very practically familiar with both Haxe, the application, and C/C++ to help with the migration.
Why?
Because as a working Haxe application, there is undoubtedly idiosyncratic code present in order to produce (or avoid) issues with the Haxe language/environment. It's vitally important that those idiosyncratic code sections are noted and the resultant idiosyncratic behavior is well-understood.
Someone who just knows the language/environment "by book" won't easily be able to identify such idiosyncratic code "in the wild". As a result, they'll instead use a "literal translation" when migrating those areas, resulting in behavior different from the original application's behavior -- or, put better, it means they just introduced defects. Worse, if they don't understand the original app's behavior really well in the first place, chances are they'll also have difficulty identifying that their code's behavior difference is the cause of the problems (or even that there is a difference in behavior).
Mixer is free even after the beta. This is now the plan since they're owned by Epic Games. And it will make Armor Paint look quite tame in comparison.
ah, sorry, seems i'm wrong about Quixel...
https://help.quixel.com/hc/en-us/ar...ixer-and-Quixel-Bridge-without-a-subscription