j3o is a file format optimized for the data structures supported by the jme3 scene graph. All other formats require some amount of conversion or adaptation, and many have options where support is ‘fuzzy’ at best, to the extent that some manual choices be to be made on import.
If it can be stored in a j3o it can be represented in a jme3 scene. Period. (And vice-versa) it also has a reputation for losing faster than most conversions.
Regarding accessibility: In many cases, conversion from your preferred asset format is the last step before an asset is shipped with the final game. If you do need to load a jme asset for editing, it’s probably best done using the jme API.
If you can’t load j3o when all if the machinery already exists, it sounds like you are not working on “evolve toward jme4” at all, but rather “build my own engine with features that I want in jme 4” which is a very different thing altogether…
Well problem is that I’m mostly working off of Vulkan documentation. And I can’t do anything about the fact that they have 0 information regarding j3o. I don’t know how j3o exactly works anyway; my point is somebody can add support, but that likely won’t be me.
I think that you are missing my point. If you are trying to build a Vulkan-capable renderer for a (currently hypothetical) jme4, you are presumably taking data from a jme scene graph (Geometry, Node, Mesh & friends) and figuring out how to feed that to a Vulkan pipeline.
If so, you don’t need to worry about .j3o support, as it’s already baked into the engine.
If you are not doing the above, you are either
building your own “not jme” engine
conducting a research project with the objective of understanding the Vulkan pipeline will enough to come back later and do the above
I’ll have a look at the binary importer/exporter, but personally thats just not something I can do, at least until the much later stages of my development.
You’ve never really used JME so you don’t even know what to keep or save… and because you’ve never used it you won’t know what’s good about it and what could be better, etc… Some of the reasons things are the way they are are really good reasons even if they look “ugly” from a certain perspective.
It’s a big job to come into an engine you’ve never really used and try to rewrite it, hoping to garner usership from the folks who currently use and support the engine.
The thing I am trying to avoid is acting like a professional when as you said, I am new. That said, this is how I want to contribute, and all options are on the table as I want to make sure the community and especially core developers like you approve.
You are new to JME aren’t you? That’s what I meant. You joined in February, don’t know what j3os are for, etc… Seems like you just happened upon JME a few months ago and got the idea to rewrite it.
It’s worth using the engine a little and getting to know how it works before rewriting it. Maybe try to make at least one simple game with it or something.
And if I’m mistaken and you’ve been using JME for a long time then you may want to try it from the perspective of the way most others use because there are still some gaps in your understanding of how the engine is used.
Me, too, sometimes… I spend a lot of time in git history because more than half the time I’m like “Why the f–k did they do it that way?” Eventually I find out why and I’m like “oooooohhhh”.
Yes I joined just last month, but I’ve worked with jme3 for creating a game for bout a year now. I’ve done plenty of java programming in the past aside from jme so I know the language pretty well.
I know I have gaps regarding jme, but I’m trying my best to fix those.
Nonetheless, it’ll be bout 5 years or so till jme4, and I figure that’ll give me plenty of time to improve along the way when I try to add Vulkan support.
it’ll be bout 5 years or so till jme4, and I figure that’ll give me plenty of time to improve along the way.
Well said i think, if you will be active and ask core related questions, learn about core core things, its very possible to make Vulkan well written for JME 5 years for active person should be enough.
Also please note some “small” questions might be made on Discord channel too.
I love the community and the engine , its what kept me here when I first started developing games. If life lets me do so, I’m here to stay and that’s why I’m trying to contribute.
For experienced Java developers using JME, typical sequence of events:
“Hey, this is pretty neat how quickly I can do that…”
“Why the hell did they do this that way? That’s really messed up.”
“Oooh… now I get it. Yeah.”
“I’m not going to use that thing because I never need it.”
…
…
Writes a thing. Asks a question about some technical detail.
Gets response “Hey, cool, but why didn’t you just use this built in thing?”
facepalm
Repeat.
My first 3-4 years of JME development… and I had JME core members treating me like I was stupid plenty of times in the core chat.
Edit: so many early chats:
Me: “Hey, Kirill… why is this thing like this?”
Him: “What?!? You want use to do it this other way that’s going to be stupid, perform badly, and murder your family and pets?!?”
Me: “Umm… no, I guess not. I see.”
lol
trial by fire.
Well contrary to the saying, Ignorance is NOT bliss, so that’s why I try to make sure all the developers especially approve of what I’m doing.
Edit: Going a ways back now, I only did what I did and started a from-scratch renderer is because whenever I look at that big a** core lib, I just want to get out of my office chair and run the other way.
But again that’s my problem, and I need to learn.