Originally posted by linuxgeex
View Post
Announcement
Collapse
No announcement yet.
LZHAM + Crunch Now Placed Under The Public Domain
Collapse
X
-
Originally posted by uxmkt View PostVery interesting graphs, in particular "transfer+processing". Too bad Zstd is considered to have just one level, when it has been like more than 12 for quite some time.
- Likes 2
Comment
-
Originally posted by illwieckz View PostWell, my comment was flagged… this code is abandonware, and did not get the last updates, please don't use it: it produces files incompatible with current software: the Unity game engine, the Dæmon game engine, the NetRadiant game level editor, etc. This other tree has performances/efficiency patches from Unity and maintenance and compilation fixes an the three main OS from Unvanquished/Dæmon: https://github.com/DaemonEngine/Crunch
crunch has two completely different modes: RDO BC1-5, and intermediate (.CRN) BC1-5. A part-time Unity engineer optimized only the .CRN mode. In the process, Unity made the .CRN encoder basically unreadable/unmaintainable. Unity didn't touch the RDO encoder at all, because they don't use it, and they could have very possibly broken it. The root code they forked from is now in the Public Domain, so they or the public can do literally whatever they want with it, including changing the license in the forked version.
Also, there are strategic and legal reasons why this code is explicitly and overtly being placed into the Public Domain, without a license, in the US (with an unlicense-style fallback clauses for jurisdictions that don't recognize Public Domain).
-Rich
Comment
-
Originally posted by illwieckz View PostSo, if you still need Crunch, please, really please not use the old code from Binomial repository. To be honest I don't know why he never merged Unity's work on Crunch. The code from Binomial repository is dead and must not be used.
The RDO BC1-5 modes are used by numerous games and some engines (like Unreal), and Unity's part-time developer didn't touch (or even test) the RDO encoder. I've thoroughly tested both the RDO and .CRN code in the Binomial repo, but not the Unity repo. If you want RDO, you can try to use Unity's repo - but good luck.
- Likes 1
Comment
-
Originally posted by richgel999 View Postcrunch has two completely different modes: RDO BC1-5, and intermediate (.CRN) BC1-5.
The question would be: is there a way to tell a file produced by Crunch is using CRN or RDO?
if yes, RDO would be out of topic when talking about CRN incompatibilities because this could be handled separately.
If no, Unity wouldn't really be in fault to have produced a variant that is not distinguishable since upstream would have done it.
Note that I don't know about RDO at all, so I don't have the answer to that question. Please answer Yes or No to the previous question so we know if you don't have to mention RDO in a conversation about .CRN incompatibilities, or we know you made two formats we can't detect at runtime and made two loaders for them.
I don't know about RDO:- There is no mention of RDO in the README in the repository,
- There is no mention of RDO in the user interface of the provided binary¹, I found no string about RDO in it,
- There is no mention of RDO in source code, there is no string about it,
- The code does not compile today on an actual Ubuntu Linux LTS, so I was not able today to try an actual binary,
- I looked at print_usage() function and I have seen no mention about RDO,
- I looked at process_files() function and I have only seen mentions about TGA, BMP, DDS, KTX, CRN, and PNG, I found nothing about RDO here and nothing to detect a file is CRN or RDO.
So, is there a way to tell if a file is using CRN or RDO?
Like many developers who are paid fortunes to work on open source projects, I don't work for free. I work on open source projects that bring in actual income from large corporations, like Basis Universal (the successor to the crunch lib)
I know what you said when you said “Think twice before open sourcing your work”. But I also know why the solution is never to not open source a work because the work is not the problem. What I know is that opensource is not about software, it's about people. I know the need for not opensourcing a work is a canary for a person to know his situation is not secured. I know that the need for not opensourcing a work is a wrong need to “live with it”, the wrong need to live with the fact were are not secured, instead of securing ourselves. I know that free software is about making sure we as people don't subject ourselves to a situation that does not secure us, because we have a canary telling us we are not secured and reminding us we need to be secured. I'm happy to see you can now take the risk to place your work not only under a free license but under public domain while you know about the risk, so maybe you're secured enough to afford that? That would be good news!
Note that at this point of my message, I may already have made numerous obvious mistakes about CRN and RDO, but that's not my concern. My concern is to provide people formats they can use. My concern is to provide people working methods and software integrating the formats they can use. My concern is to provide people software that can detect and load correctly the format they can use. Not understanding RDO and CRN is not my concern. My concern is to be able to provide one loader per format, this requires ways to know about and detect the format, this requires up to date documentation not to describe the variants but to name the variants, this requires bits in the format dedicated to detect the variants.
If you understood what the library does
Also the described problem you answer to is not about understanding this or that more or less than any level. There is no competition about understanding, neither in knowledge. The topic is all about making people have their needs fulfilled thanks to various people understanding a bit of this or knowing a bit of that, not everything.
This thread is about knowledge. The same way you are able to acknowledge I can understand things that are not in your own scope I can acknowledge you can understand things that are not in my scope. I can acknowledge the name of the format variants, the way they can be detected, the way different loaders can be implemented for each variant, etc. Where is the knowledge about RDO? Where is the knowledge about detecting format variants and implementing different loaders for each variant?
The RDO BC1-5 modes are used by numerous games and some engines (like Unreal), and Unity's part-time developer didn't touch (or even test) the RDO encoder.
Why do you mention that the developer was part-time? I don't need to know if you are part-time. You don't need to know if I am part-time. What is this information about?
Unity optimized my first .CRN encoder, but not my second RDO encoder (which I optimized a great deal, years ago)
If you want RDO, you can try to use Unity's repo - but good luck.
The statistics you're talking about are only for the .CRN mode, which few games/engines outside of Unity actually use because the transcoder is too slow.
Maybe Unity's effort to reduce CRN slowness is still far behind what you did on RDO. But those are different formats, right? We can make two loaders, right? That must not be a problem is Unity's CRN is incompatible with RDO, right? You said it's completely different, right?
The root code they forked from is now in the Public Domain, so they or the public can do literally whatever they want with it, including changing the license in the forked version
So, is there a way to tell if a file is using CRN or RDO?
Also: how to select CRN mode or RDO mode with Crunch?
crunch has two completely different modes: RDO BC1-5, and intermediate (.CRN) BC1-5
Note that I said that within the boundaries of that topic I already know about you, but in fact you already know about me.
I have one issue opened since 2017 on your BinomialLLC's crunch repository:- https://github.com/BinomialLLC/crunch/issues/11
This is a cross-platform compilation issue (32/64bit)
- https://github.com/BinomialLLC/crunch/pull/13
It's the fix for Linux compilation on 64bit platform (the issue I just talked about), - https://github.com/BinomialLLC/crunch/pull/14
It's a fix for a type issue, - https://github.com/BinomialLLC/crunch/pull/12
It's a feature implementation.
- I was the one reporting you the issue,
- I was the one shipping the fixes up to you and making sure they are rebased on your latest tree,
- I was the one giving you knowledge about the errors and the fixes,
- I was the one giving you knowledge about the needs and the features,
- I was the one who put you in touch with the specialists who implemented the fixes and the features, those with whom you can talk about understanding.
Well, I was curious and I looked at the reason why I'm not able today to compile and run your tool, the last version of your branch, the one you just set in the public domain. The reason I cannot compile that tool on a 64 bit Linux system in 2020 is the error I reported you in 2013, the error I delivered you a fix for in 2013.
I know the other Crunch tool based on Unity enhancements and maintained by Dæmon/Unvanquished compiles on Windows, Linux and macOS, and I know the CRN library from that other tree is integrated in game engines running on those OS, and I know the CRN library form that other tree is integrated in game edition tools compilable and running on Windows, Linux, macOS and FreeBSD. Knowing those things is part of my concern, alongside the efficiency of the tools. Until today I have found no knowledge about RDO from your tree, and the Linux 64 bit fix for your tree is yet to be merged after three years.
I said earlier that if one day we have to do things together it would be because each other would have something the other doesn't have. You see, I know the true strength of patience and after three years I know it's still possible to do things together. I'm still there.
- Likes 1
Comment
-
Originally posted by illwieckz View PostI have three pull requests opened since 2017 on your BinomialLLC's crunch repository […] The reason I cannot compile that tool on a 64 bit Linux system in 2020 is the error I reported you in 2013, the error I delivered you a fix for in 2013.
Anyway, no one pull request from anyone got merged in your tree after January of 2017. There is no code change since this date. All commits since January of 2017 in your tree are readme and license tweaks. The Unity tree is based on the latest version of your code (the only missing commits are some about readme rewriting and license wording).
Because my concern is to make and keep Crunch usable and to prevent fragmentation, the Dæmon repository hosts five special branches:- https://github.com/DaemonEngine/crunch/tree/googlecode
The original tree that was hosted on Google Code, - https://github.com/DaemonEngine/crunch/tree/binomialllc
Your actual tree on Github, - https://github.com/DaemonEngine/crun...e/unvanquished
The original tree previously used by Unvanquished/Daemon with patches sitting on top of a now old version of your tree, - https://github.com/DaemonEngine/crunch/tree/unity
The Unity tree, - https://github.com/DaemonEngine/crunch/tree/master
The current tree maintained by Unvanquished/Daemon with patches rebased on Unity tree.
The Crunch tree maintained by Unvanquished/Daemon provides:- Your own tree up to the latest code-related commits you made,
- Unity patches above your own commits (making the code faster and producing smaller files),
- Linux 64bit compilation fixes (make crunch and software embedding crnlib to compile on this system and architecture),
- Fix for malloc in crn_decomp on macOS and FreeBSD (make software embedding crnlib to compile on those systems),
- Support for user-supplied definition of CRND_ASSERT to be used in (make crnlib easier to embed in an software),
- CMake support (make software embedding crnlib easier to integrate crnlib in the toolchain, also install crunch the File Hierarchy Standard way),
- Makefile fixes (to make compilation working again for those who may still rely in it),
- Option for top mip-level renormalization (a special option for normal maps to make Z reconstruction easier when using DXT5/BC3),
- A first class embedding in other software when used as a git submodule.
Also, if what you call RDO is not a format but some decision optimization techniques (maybe the ones used by the -bitrate option I've never seen used?), 90% of my previous comment is still fully relevant because as I said, mistakes I would say about what is RDO is not a concern: my concern is to keep Crunch being alive, being usable and fits the need of users.
Today the Unvanquished/Damon tree of Crunch is probably the only one making it possible to compile and run the Crunch tool outside of Windows and to embed crnlib in software with neat submodule integration and toolchain integration with compilation supported on four operating systems.
Originally posted by richgel999 View PostAlso, there are strategic and legal reasons why this code is explicitly and overtly being placed into the Public Domain, without a license, in the US
- Likes 1
Comment
- https://github.com/DaemonEngine/crunch/tree/googlecode
Comment