love anime 
but some people dont like it, need be carefull.
but well, Genhin impact is popular recently 
2 Likes
To me, the different scenes should be as different as possible anyway.
3 Likes
well, you are right, so we can have Anime style too, thats right!
not sure if we can use other Games similar assets tho. If its not commercial, then could be fine, someone should tell if we can.
2 Likes
I am interested to know this too!
It looks like the ones you linked are all listed as the ‘creative commons attribution’ license on sketchfab which even allows commercial use - so I think they probably want people to use their assets to spread the visibility of their game, and out of generosity as well I imagine. We’d just need to list their name/company in the credits somewhere to attribute them for their work.
Sketchfab has another license called ‘CC Attribution-NonCommercial’ that we may want to avoid - although we might still be okay with those since this isn’t technically a commerical project, but idk for sure on that.
So I guess its not a question whether we can, but whether we should. I would avoid using another game’s assets for my own game, but this is just a graphics demo project so I don’t see why we wouldn’t be able to use them as long as we make a good anime-style room to match with them.
1 Like
I could imagine a small fantasy island with a fantasy sky and water around and a bunch of trees and flowers and a few wooden houses, with some birds sound in the environment and a campfire.
A character in the jungle looking at some animals, another character sleeping next to campfire, two of them standing next to the beach saying lovely words. 
2 Likes
Even typical lawyers have problem with it(would need find one that knows all this topic, also lawyer specialize in different areas, here is probably Intelectual property one, same as for Trademarks, i have contact only with one that is TAX related specialist). But generally i think its simple:
Author of this model, is not same author of Design.(he cloned design)
so when he write license, i assume it only refer to himself, but not Design author. Anyway on google there are many topics about things like this and seems like we should be carefull, so IMO best if we could find “same good looking, non-existing-game anime characters”. I would love to use the ones Ali linked, but its up to someone to take this risc. Unless someone will find that we can just write “all asset designs do not belong to project authors” maybe? anyway most carefull is just avoid it.
1 Like
We should avoid assets that are obviously from another game. For a few reasons.
- the legality is questionable and why create trouble?
- if someone sees only a few seconds of our demo (or youtube clip) they might think it’s the other game and not our demo.
Exceptions would be assets you own from a JME game, of course… if they are nice enough to use here.
2 Likes
I did not notice that, yeah that makes it more complicated
I suppose the author of those models should have it listed as non-commercial, since its technically fan art then. I’d think that a lot of people will be fine using them still, since most projects won’t ever reach the attention of the original game’s creators.
But you’re right we should probably just use more original assets to avoid any trouble.
1 Like
I can help supplying animated characters from mixamo.com such as these one:
Capoeira Character Demo - Viva Brazil - YouTube
I’m using Blender to combine the animations and the result is fantastic most of the times…
1 Like
Wow, I didn’t expect so many answers in one day! Cheers Guys!
Unfortunately I have to remind you to try to stay away from the details/later stage work for now, though.
Only two replies really addressed the question about ideas and themes.
This is especially about the guys already searching models. I appreciate your energy, please keep it, but that’s two steps ahead. Please try to wait until we know what models we need, it will make searching/deciding much easier for everyone.
For instance there have been a lot anime models, but I’d like to use Jaime as much as possible (i.e. only use different models where the showcase requires it, e.g. lip sync with mixamo or say a fortnite dance).
The other guys have addressed a few interesting topics, but even there, we should probably discuss the underlying basics before coding too complicate stuff, e.g.:
There has been talk that a sci-fi corridor with airlock doors is hard to find.
I’m against sci-fi anyway, because it won’t really fit our Museum of Modern Monkeys theme (I mean we haven’t decided yet, but if we’d go sci-fi, we would need to make it all around sci-fi. I guess that limits us).
There are two things to consider here:
-
I would say we don’t have a corridor with 100 doors, but you start in one room and in the end of the room there is a door, which is also the loading screen. That’s the Airlock mechanic, but we are free to do this differently (e.g. a big wooden door with some gears grinding until all of the 100 bolts have unlocked and then it moves slowly. Another approach could be a portal building up and then the loading screen being “travelling the portal”).
-
Maybe we can consider preloading in our AppState concept, because at least for the
seatedexperience, we can perfectly preload stuff, ifXmxis high enough.
Another thing why I say don’t code too much yet is the controls: We haven’t yet decided on that.
In my vision it was like you can walk around freely (when not being seated).
@RiccardoBlb had the idea of like a train ride (it would match with the Half-Life Train as well), where you can only look around freely, but not see the scene from behind. That’s certainly a big difference for us!
TLDR: Please do not try to get into deep model search, try to have idea search first.
Speaking of VR, I am certain @grizeldi will rewrite the VR bindings for us. Thanks for that already 
Just one more comment on the game template idea:
That is something that perfectly fits for out-of-engine contributors and it has already been done, there are a few templates out there.
One problem we have with that is: We already have a few templates for 3.0, but noone knows about them anymore, we virtually don’t support them, because we would have to get into them again etc.
Furthermore, there could be a lot of different approaches for the templates.
It will also be a lot of duplicate code to be written.
This and the ITCH GameJam are just not possible at our current size I would say.
Nothing against it in general, but I guess we would need to be larger to “officially” do this.
That doesn’t mean the community can’t do it. I think jay had an FPS Demo done right before he left, e.g.
Just being picky: I still think it should be so well formed that folks can extract some techniques into their own games, but I do agree it doesn’t need to be educatory or meant for beginners.
I disagree a bit here. I don’t see a reason to rush something together. This project will probably be our public image for the next ~5 years (unless another significant approach appears), so we should be considerate and try to do the best we can. So being minimal is something I’d not recommend either. It should rather show of everything that is possible and take more time.
That being said I understand if folks themselves don’t have enough time to put in this project, that’s a different story. But it’s not like we need to be done by the end of this month or even year. We’re done when we’re satisfied. At least that’s my view.
I think there are two things here: We don’t really have out of the box cell shading and others to really have an anime scenary. It could probably need some comic water shader as well etc. That’d probably be some work.
The other point is: The “uploader” might give you permission to use them, but they could still be illegal.
If the uploader just extracted the models out of the game, it’s a copyright infringement right there.
Even if the uploader models a car, you can’t use it in-game without violating patents/copyright/whatever.
I see you’ve talked about this already, but yeah, just for clarification again.
If I overlooked some post, just tag me directly and I’ll reply.
That has been a wall of text and I love it, because it shows movement I wouldn’t have thought we have!
2 Likes
!remindme whenever lwjgl bothers to add OpenXR bindings. I don’t mind getting my hands dirty with low level VR APIs, but I have virtually zero experience with writing java bindings for native libraries.
I agree that there just aren’t enough people that would be willing to participate in such a jam. That said, someone should really submit jme to itch, as last time I checked, I couldn’t tag my games on there as “made with jmonkeyengine”, as jme is missing from their lost of gamedev tools.
Proper toon shader is impossible until we add support for in pass shadows. I got a shader done already, but as soon as I tried adding shadows, the looks went downhill fast due to the way our shadow renderer works.
Porting a toon water shader sounds like a cool weekend project though.
1 Like
I’ve built a quick prototype, and now i think i can better elaborate my proposal.
If we want to get as much people as possible onboard with this, we need to design something that is esily extendable and can allow contributions without prior knowledge of the entire code base, and that can be fruible also from people that do not have much experience with the engine.
This incorporates some proposals made in this thread too.
The logic is part of the world
We all know about the trend of decoupling graphics from logic, all its benefits and such.
But for this project, i believe it introduces unnecessary complexity.
What i propose instead is to use a more natural approach, where all the things that exist in the world are defined as Spatials and their logic is defined as Controls. If there is logic, there is a Spatial to which it is attached. For this reason I also discourage the use of AppStates in favor of controls attached to the more appropriate parent node.
Root nodes
In jme you can have multiple viewports and multiple root nodes, some root nodes might be part of the world, and some not. In our application we will simplify this by saying all our root nodes will always be part of the world.
GameControl
A GameControl is an extended Control that will be used to write the logic. This control can know when it is actually attached or detached from the scene (that doesn’t always correspond to the addControl/removeControl calls). And exposes a different set of overridable methods
public class MyGameControl extends GameControl{
@Override
public void onInitialization(SimpleApplication app, Spatial sp) {
/**
* Called when the control appear in the scene graph. It should initialize all the logic
*/
}
@Override
public void onDeinitialization(SimpleApplication app, Spatial sp) {
/**
* Called when the control disappear from the scene graph. It should deinitialize all the logic
*/
}
@Override
public void onSpatialSet(Spatial newSpatial) {
/**
* Called when the control is attached to a spatial
*/
}
@Override
public void onSpatialUnset(Spatial currentSpatial) {
/**
* Called when the control is detached from a spatial
*/
}
@Override
public void onRender(RenderManager rm, ViewPort vp, Spatial sp) {
/**
* Called everytime the spatial is rendered
*/
}
@Override
public void onUpdate(float tpf, Spatial sp) {
/**
* Called from the logic update loop
*/
}
}
The GameControls should always clean after themselves. If they change properties of the application when they are initialized, they should restore them when they are deinitialized.
Subscenes
The application will be composed of multiple subscenes into which the player can transition.
We will use f3b to load from blender into jme with 1:1 mapping.
Each subscene will be contained in a parent node
Each subscene’s parent node will have a GameControl attached, that will take care of
- initializing the scene (eg. attaching more controls, loading more spatials, changing application settings, loading a background music)
- detecting the player entering or leaving the subscene and changing its behavior (eg. transforming an fps player into a vehicle and back when it leaves the subscene)
- culling and optimizing the subscene (eg. some subscenes might need to be removed if the player is too far away)
- deinitializing all the above and restoring the player behavior when the player transitions to the next subscene. Every subscene should clear after itself, so that the next subscene doesn’t have to deal with leftovers. It might be possible,however, to allows the player to carry things from one scene to the other, as long as they don’t interfere with the next scenes (eg. visual changes might be ok)
Linked subscene
F3b can support the Link feature in blender.
Meaning we can use different blend files for each subscene, and have a main blend file that composes the world together.
Every subscene can be exported to a different f3b file and the f3b runtime will recompose them together during the loading of the main scene.
Contributors can work on their subscene, without interfering with others work.
Hold out subscenes
When a collection is marked as holdout in blender 2.8, f3b exports only the node structure of the scene.
This can be used to holdout entire subscenes while still having them linked into the main scene.
The GameControl attached to the parent node of an holdout subscene can perform lazy load on it by loading the subscene from the assetManager only when the player is close enough.
This can be used for very heavy subscenes or to load non f3b subscenes.
The Spatial UID
(In my prototype i called this UID,unique id, but i then realized it was more flexible to have it assignable to more than one spatial, so the name should be changed).
The spatial (U)ID is an user property we will use to identify a spatial, or a group of spatials, inside the scene.
There will be an api that just returns all the spatials having the specified spatial.uid inside a parent node.
AutoAttachToSpatial
The next problem to solve is finding a way to attach a GameControl to a subscene parent without having to manually add code to the application init method, or to some common appstate.
The solution I’ve found is to use annotations to link spatial uids to GameControls.
Similar to what is done in spring or other libraries, we can annotate a class with @AutoAttachToSpatial(uid="UID"), like so
@AutoAttachToSpatial(uid="scificorridor1")
public class ScifiCorridorSubsceneInitializer extends GameControl{
}
After the main scene is loaded, a spatial with the specified uid will be found, and a new instance of the GameControl will be created and attached to it.
This means we can contain all the logic for a subscene into its dedicated package, and an initializer GameControl annotated with @AutoAttachToSpatial will perform the initialization, without the need to modify common application code.
Transition between subscenes with a railway
The standardized way to move between subscenes will be a railway
A railway is composed by the railway itself and multiple stations.
The stations define the beginning and the end of every railway section.
A station can have a clickable button that triggers an action that pulls the player under the railway to which it is then attached. I was thinking about using a physics joint or a serie of waypoints for that (more research needed).
When the player reaches the next station, it is detached from the railway.
What we will use
- f3b for scene/physics loading
- jmePhonon for immersive audio
- bullet/minie for physics
- Lemur for ui
Other libraries can be used for specific scenes at the discretion of who is making the scene
7 Likes
So GameControl is reimplemting a lot of AppState? And then if the GameControl needs to register other app states then it will have to manage those?
Seems an odd choice and requires some strange gymnastics that wouldn’t be required with a composite app state approach.
2 Likes
No, it goes the opposite way of an appstate.
An appstate is global, the GameControl is relative to the spatial to which it is attached.
From a GameControl you can easily access other GameControls local to the same spatial. For example a RayPickerControl can access the FirstPersonControl and get the position and direction of the head.
Doing this with appstates would require to maintain queues of states and associations with the spatials. It is not as modular as the control approach.
The gamecontrol also doesn’t reimplement the appstate code.
Yeah, but this is for the root node of the ‘scene’, right?
…which is global at the time it’s in use. And that’s why you have an initialize method, etc. to make up for the fact that it’s not an app state.
It seems to me to unnecessarily urge the ‘scene’ to only have a root node, no guidNodes, etc… all life cycle associated with one node.
An app state seems a better fit for a ‘sub game’.
Edit: it occurs to me that I may have misunderstood the point of this project. It seems to be “show that blender stuff can be loaded in JME with PBR and physics”. And I thought it was a show case of the different things that JME can do. So maybe ignore me.
Oh no, those are for the subscenes, that are always loaded in one form or another in the scenegraph, since the player can transfer between them.
The onInitialization/onDeinitialization methods are relative to the control , not to the scene. The onInitialization method will be called on the first tick of the controlUpdate, the onDeinitialization will be called when the control is removed or the spatial is detached from its parent.
That’s just relative to the GameControl logic.
GuiNodes, offscreen rendering etc can still be used. The assumption that ahead of the scenegraph there is always a rootNode that exists in the world, simplifies the development of the logic in the GameControls.
You haven’t misunderstood. But it doesn’t need to be a pure tech demo, it has to be a showcase that not only show the features of the engine, but is also visually appealing.
I will upload the prototype in the next days, because code sometimes explains better than words.
1 Like
I don’t know if that won’t conflict with our goal of having the best quality optically and the code being capable of being taken as an example for others in their projects.
This to me would be a question of world logic and spatial logic, I’d say. I mean, yes, we could add everything that would be an AppState to the rootNode, but if it’s only to appeal more to untalented programmers, that’d be a no. Like everytime something applies to multiple nodes, it could just keep a list around.
That’s the point where we loose a lot of people and make it too specific.
Also we shouldn’t do it like that, but instead load sectors on demand, to have faster loading times and less RAM usage.
Especially as every subscene does not need real connections to the others. We could even teleport between them or something.
In general the ideas sound a bit like a prototype of a more artist friendly jme in general, but we want to see the current state rather. I guess that’s what aul meant with
Besides:
We’re still in dire need of ideas or at least libraries you’d like to see included, so we can get started.
I mean there are probably a 100 uses cases based on physics alone.
Then we have two Particles implementations that need to shine
Fancy new animations.
Please bring the ideas on!
im not against f3b, its probably awesome, but its same like .Blend importer as i know, need update each new version of Blender. We could load on demand using f3b so its not argument for me what you said, but rather the one i said above.
About what libraries we would like to see included, lets just make Vote for it imo. Myself i already suggested some libs, i hope more people will suggest something.
The one thing is sad, that one person will prefer one solution, while other second, i hope even if someone will not like the chosen solution, will help anyway.
Still, someone need prepare basic DEMO(with just cubes/rail) some kind of kickstarter, so we will see which one is easier to understand and cooperate with. Anyway still, this should be mainly to show that JME Graphic can look really good. Since none of engine-searching-people will look how you exactly done it, they will look “what can be done and how it look”. Later when they join, then they will look how to done this thing exactly, and then it comes that Demo should be made easy way(so this people will see its not hard to do also), but its not priority here imo.
1 Like
The blend importer imports the blender internal structure directly. It needs to be updated often because the blend internals are not made to be imported directly, it also cannot leverage the blender apis (that work on those internals) without reimplementing them in jme.
F3b is just another format like gltf, with the difference that it is tailored specifically for jme.The exporter uses public apis, that do not change often, since when they change it means they are breaking all the existing plugins (not just f3b). Recently we’ve seen this only when blender was updated to 2.8.
And anyway updating an exporter that uses documented apis is much faster.
I think we should follow the path that gives the best result with the lowest effort. The design i proposed allows to optimize ram usage and loading times without building abstractions.
JME is always presented as this complex engine that needs several level of abstractions, planning and a lot of code to do even the most basic stuff.
But that’s not the only way to do things.
What i proposed is more artist friendly, it caters to less experienced developers, yes, so what? We are not trying to gatekeep the engine only for who we deem to be a real developer.
4 Likes