You know what I am really hoping for on your format ?
To protect assets.
Currently the main issue I have with Jmonkey is the assets exposure, and I am not alone.
Anyone can get your j3o files , convert to blender and modify re-use etc, if you have contracts with your artists, you are lost.
Using your format if I understood how it works, would fix in parts this problem because you could obsfucate it, even using an week formula would give you an good protection, and if you want max protection, there is some payd professional obfuscators that are actually good.
There is no converter that goes in this direction. In that sense, j3o files are perfectly protected since you can only access them in the engine are by code. âperfectly protectedâ being a total misnomer because it is provably and physically impossible to âperfectly protectâ assets.
xbuf is more meant to be an interchange format so is less protected.
Well, yes, but since the data is already being serialized, then shouldnt be hard to make an extended spatial class generator for the scenes, but I am guessing here, maybe the OP could take my doubt out.
There is some good obfuscators out there that could make very hard ( not impossible I know ) to uncompile and extract models from codes.
About the j3o, there is some peaple building blender exporter to j3o, normally when you build exporter you also build an importer, so its my consern that j3o will not be close anymore, an encrypt option would be nice if it happens.
I know there is not way to prevent 100% way to protect your models, even in c++ engines, but currently, any C++ engine is better just because its much more harder to extract assets / textures / etc.
You know, I hear all the time investors and other coders saying pure java engines are not good just because of this, and I cant really say anything againstâŚ
from xbufâs FAQ :
How can I protect my content ?
- change the file extension
- modify the file content, example of modifications (can be combined) :
- wrap into your own proto Message
- add an header at the begin of the file (a fixed or variable size of useless bytes, some license info)
- encrypt : rot13, pgp, âŚ
- wrap into an archive (but without the reguler extension): tar, zip,âŚ
- compress (but without the reguler extension) : snappy, gzip, bzip, lzma,âŚ
That is the myth, yes. 10 minutes in a debugger can prove otherwise.
If the code can load it to use in the game then the data is easily accessible to anyone with the executable.
It doesnât change the fact that itâs ILLEGAL TO COPY anyway⌠even if you include a raw .jpg right in your zip itâs still stealing if someone else uses it. Thatâs the funny part.
The last half of this is completely without merit. There is no logical reason one would build a j3o importer for blender just because they want to export j3o. Itâs easily twice as much work for no good reason. (Itâs one thing to export a small subset of something and a completely different thing to try to import all of something.)
So, unless you specifically hear that someone is building a j3o importer for blender, any statements of such are as credible as suggesting I will grow wings tomorrow.
I agree with you and even with @pspeed , but my investors unfortunately dontâŚ
You know, the problem is that this guys just say that if even for someone that knows nothing of technologies is able to google âhow to open an file called assets.jarâ and how to install and use an plugin on blender called âopen j3o filesâ, so they conclude this engine dont protect any assets at all.
Anyway, I would like to know more about how you are planning the protection stuff, can I take a look on what you already have for the .xbuf file reader ?
You should really implement your own protection layer then. Nothing stops you from using your own asset loader that decrypts files and then uses the regular loader.
If it is just about that,l just encrypt all assets with some xor then. and modfy the assetloader/locator inputstream to dexor it on the fly. That way no directly readable data is on disk.
Or even simpler⌠just add an extra byte to the end of the file (jars/zips/etc have their index at the end as I recall) and then strip it off in a custom loader. Change .jar to .mfd (magic fairy dust) and tell your âinvestorsâ that you have asset-protecting magic now.
Tadah, âprotectedâ assets.
1 Like
Good luck with this oneâŚ
I fell a bit more tranquilized that you guys (core devs) have guarantee that such thing dosent exists and its not planned to be built, at least not yet.
Anyway, since this topic was moved from the original one and the awsers are more in the line of âbuild something yourselfâ and notthing about xbuf, I think its already out of topic.
You see, I was already planning since the beginning to build something myself, the main question here was if xbuf would have such feature, as it seens it will not have, there is nothing really else to discuss about it.
Yes itâs out of the scope of Xbuf.
You have to build yourself the âprotection layerâ over data formats (xbuf, j3o, jpg, png, ogg, âŚ) with some suggestion about how to (see my first reply above copied from Xbufâs FAQ).
Thanks for your interest for xbuf.
1 Like