@oxplay2 said:
this is very similar to "getPixel" topic, really.
edit: yeah, plugins could be best way to solve it..
Hmmm.. are we seeing a pattern here possibly?
I'm all for plugins though, I also agree that something like SSAO should not be part of core. Why would I want to redistribute something I am not using? Unfortunately, I would have to lump JBullet in with that as well. I have no need for the physics for my current project... it's a lot o stuff that gets wrapped into my game for no reason.
@t0neg0d said:
Hmmm.. are we seeing a pattern here possibly?
I'm all for plugins though, I also agree that something like SSAO should not be part of core. Why would I want to redistribute something I am not using? Unfortunately, I would have to lump JBullet in with that as well. I have no need for the physics for my current project... it's a lot o stuff that gets wrapped into my game for no reason.
Bullet is only distributed with your app if you use it.
As pspeed said core is already split into multiple libraries and you can include just the ones you need (that’s what we do).
Really what is needed is for a categorized plugin system.
You would then have for example Shadows, Filter, Shader, Image, SDKTool, etc category in the plugins. Within those would be user contributed plugins with a description, version number, last update date (or something similar so you can see stuff that’s actively maintained vs stuff that has been abandoned). Maybe a flag to say that it’s actively maintained.
All existing shaders, etc would get moved into the plugins as well.
So now as a user I go “I need shadows”, so I go to the plugins - I go to Shadows category and inside that I see PSSM, Basic, SSAO, BasicAO, etc and I can try them out and pick-and-choose as needed.
@zarch said:
As pspeed said core is already split into multiple libraries and you can include just the ones you need (that's what we do).
Really what is needed is for a categorized plugin system.
You would then have for example Shadows, Filter, Shader, Image, SDKTool, etc category in the plugins. Within those would be user contributed plugins with a description, version number, last update date (or something similar so you can see stuff that's actively maintained vs stuff that has been abandoned). Maybe a flag to say that it's actively maintained.
All existing shaders, etc would get moved into the plugins as well.
So now as a user I go "I need shadows", so I go to the plugins - I go to Shadows category and inside that I see PSSM, Basic, SSAO, BasicAO, etc and I can try them out and pick-and-choose as needed.
While I'm a big proponent of decoupling and since I opened this particular can of worms, I wanted to say that I think the engine does well to have some standard shaders in. They are small and many of them are tightly coupled to how the engine works... so at worst they are a great starting place for someone writing their own. Lighting.j3md is an example of something that can nicely evolve with the core engine's lighting capabilities and the users who use that will see relatively little impact except their games may run a little faster, look a little better, or have more lighting flexibility.
I know it seems I have been hesitant to do this, but I do have some valid reasons for not having done it thus far. @zarch mentioned a few for sure… which would have an impact on the biggest question I have about it…
I have a ton of contribution… wrapping them into one plugin is potentially a bad idea. However a million different plugins is a bad idea as well (no one will be able to find anything that they need because they have to filter through 50,000 plugins posted by me… not to mention another 70,bazillion posted by others.
How should I handle this? Do I wrap them all into one and force people to download all of them, even though they may only want the skydome? Or?
Any assistance with how these will eventually be categorized would be very helpful.
EDIT: Actually… another issue with bundling them is, no one will known at first glance what it contains. If they are specifically looking for SSAO… they may never see the option.
I think “too many plug-ins” is a problem that we’d like to have. And then there are probably solutions for that issue.
Group contributions together that make sense to do so or that tightly depend on each other. Separate the rest. From experience in general, it might be best to start with larger ones and then split as needed.
The code we’re talking about is small anyway (bytes-wise) so having a few extra things along for the ride is not too bad. Obviously if one feature requires 30 meg of data files… probably best to split that out, etc.
@pspeed said:
I think "too many plug-ins" is a problem that we'd like to have. And then there are probably solutions for that issue.
Group contributions together that make sense to do so or that tightly depend on each other. Separate the rest. From experience in general, it might be best to start with larger ones and then split as needed.
The code we're talking about is small anyway (bytes-wise) so having a few extra things along for the ride is not too bad. Obviously if one feature requires 30 meg of data files... probably best to split that out, etc.
This seems like it hasn't been actually considered past... this solves our immediate problem. Everyone is asking that we contribute this way, but no thought has gone into the impact it will have when people start doing this as the norm. The thought "Impending Cluster-F" comes to mind.
@pspeed said:
B) the problems are not so great anyway. Even a thousand plug-ins would be manageable with some better categorization. I'd be very surprised if we see even 100.
@pspeed said:
While I'm a big proponent of decoupling and since I opened this particular can of worms, I wanted to say that I think the engine does well to have some standard shaders in. They are small and many of them are tightly coupled to how the engine works... so at worst they are a great starting place for someone writing their own. Lighting.j3md is an example of something that can nicely evolve with the core engine's lighting capabilities and the users who use that will see relatively little impact except their games may run a little faster, look a little better, or have more lighting flexibility.
So there has to be a balance.
I'd agree for those two shaders, and potentially for the differed rendering stuff that people are working on as that might need hooks into the core. Things like the various shadow/glow/bloom/etc filters though are classic cases for plugins.
Nm… netbeans is retarded. You have to cancel out of creating the new module after adding the platform and start the process over again and then it recognizes it as a valid platform. /boggle
This one I probably won’t find the answer to myself:
Step something: To use core SDK or jME3 functions, add “jMonkeyPlatfom Core” and “jMonkeyEngine SDK Core jME3” via “Module Properties→Library→Add Dependency”
This doesn’t seem to include the changes made to nightly. It’s impossible to add a working Filter without the update made to:
Another issue I’m not sure how to resolve… did I miss a step somewhere? When attempting to build a non-filter module I get this error:
C:Userst0neg0dDocumentsjMonkeyProjectst0neg0d-SSAOt0neg0d-ssaobuild.xml:7: The following error occurred while executing this line:
C:Userst0neg0dDocumentsjMonkeyProjectst0neg0d-SSAOt0neg0d-ssaonbprojectbuild-impl.xml:22: You must define ‘nbplatform.jMonkeyEngine_SDK_3.0beta.harness.dir’
Looks like your platform definition is borked. In the SDK check Tools->Netbeans platforms that there is a platform defined there. Also check $HOME/.jmonkeyplatform/3.0beta/build.properties
The NB build system is… extra special. It uses something called a harness to build your module for a specific platform (so that you can vary the target system). It is looking for the harness directory using the “platform” name but fails to find it. It usually finds this information using a private file (thus the $HOME).
@t0neg0d said:
Nm... netbeans is retarded. You have to cancel out of creating the new module after adding the platform and start the process over again and then it recognizes it as a valid platform. /boggle
@jmaasing said:
Looks like your platform definition is borked. In the SDK check Tools->Netbeans platforms that there is a platform defined there. Also check $HOME/.jmonkeyplatform/3.0beta/build.properties
The NB build system is... extra special. It uses something called a harness to build your module for a specific platform (so that you can vary the target system). It is looking for the harness directory using the "platform" name but fails to find it. It usually finds this information using a private file (thus the $HOME).
Yes, for some reason the current version of the SDK doesn't contain a proper harness directory.. I can only fix this with a new application release, so hopefully from RC2 on the SDK development part should become less of a hassle to set up :/
All existing shaders, etc would get moved into the plugins as well.
So now as a user I go “I need shadows”, so I go to the plugins – I go to Shadows category and inside that I see PSSM, Basic, SSAO, BasicAO, etc and I can try them out and pick-and-choose as needed.
Exactly, IMO this is how it should be done. Then even not code Tested(via developers) plugins could be added. So users could have big amount of possible choices.
I’d agree for those two shaders, and potentially for the differed rendering stuff that people are working on as that might need hooks into the core. Things like the various shadow/glow/bloom/etc filters though are classic cases for plugins.
don't know about shadow, since it is related with Light shader(if im not wrong), but others yes.
Uhm… Just now noticed what else is going in this thread.
@t0neg0d: Please, consider that this engine is our baby. We even allow you to clone it and raise it yourself and give you all data and papers for free. But let us raise it the way we want to do it. We have already seen what happened to the child we cloned the heart for ours from and it was due to uncontrolled additions. We have ZERO obligation to use code anyone created, no matter how much time they invested. When julien from the JOGL project came here and wanted us to add the JOGL renderer he was kind of on the same line or argumenting. He said its “unfair” not to add JOGL and that its better than LWJGL. While he might be right with the latter he certainly isn’t with the first. This is the product we want to create and put in this world and we know it better than anyone because we created it. While we might be wrong with some things or don’t know others, its certainly not our “ego” making us protect the engine but its our geek love towards it. We do not want it to end up like jME2. If that causes it to become another problem child, well, maybe you and phate will be the jME4 team getting the balance of control and contributions right
If you want your changes and ideas directly in core, make a contribution that we can use as is in the engine (best of a missing thing and not some re-implementation) and come to the core chat. Then manage to stand us for three weeks and receive the secret initiation ritual. Thats what everybody had to do to get in with code. Then you can do with the engine what you want. Given you win the arguments in the chat that ensue each new feature
Peace, we all like what you do and it does help the engine. Just don’t do this:
normen said:
Yes, for some reason the current version of the SDK doesn't contain a proper harness directory.. I can only fix this with a new application release, so hopefully from RC2 on the SDK development part should become less of a hassle to set up :/
Yes I've noticed when setting up a headless build on my CI-machine :)
I don't know how you are building this but if it is through the SDK then it should work, I can build modules and modules suites from there.
If it is from the command line, this is how I do it on my jenkins build sevrer (and it isn't pretty):
I tell ant the following:
-Duser.properties.file=/[some directory]/build.properties -Djava.awt.headless=true
The build.properties I point to has the following:
nbplatform.jMonkeyEngine_SDK_3.0beta.netbeans.dest.dir=/[where jmonkey SDK is installed]
nbplatform.jMonkeyEngine_SDK_3.0beta.harness.dir=${nbplatform.jMonkeyEngine_SDK_3.0beta.netbeans.dest.dir}/extra
Now if you look in the "extra" directory it should contain a build.xml.
If it does not you will need to go into the SDK and install the "Netbeans Plugin Development".
What this does is to create the needed "harness" files, but they end up in the "extras" directory. Which as normen points out isn't the proper harness directory but it should do for now.
Hope this helps (and don't ask how I know this stuff - I actually don't, it is more conjecture and voodoo than science).
@normen said:
Uhm.. Just now noticed what else is going in this thread.
@t0neg0d: Please, consider that this engine is our baby. We even allow you to clone it and raise it yourself and give you all data and papers for free. But let us raise it the way we want to do it. We have already seen what happened to the child we cloned the heart for ours from and it was due to uncontrolled additions. We have ZERO obligation to use code anyone created, no matter how much time they invested. When julien from the JOGL project came here and wanted us to add the JOGL renderer he was kind of on the same line or argumenting. He said its "unfair" not to add JOGL and that its better than LWJGL. While he might be right with the latter he certainly isn't with the first. This is the product we want to create and put in this world and we know it better than anyone because we created it. While we might be wrong with some things or don't know others, its certainly not our "ego" making us protect the engine but its our geek love towards it. We do not want it to end up like jME2. If that causes it to become another problem child, well, maybe you and phate will be the jME4 team getting the balance of control and contributions right ;P
If you want your changes and ideas directly in core, make a contribution that we can use as is in the engine (best of a missing thing and not some re-implementation) and come to the core chat. Then manage to stand us for three weeks and receive the secret initiation ritual. Thats what everybody had to do to get in with code. Then you can do with the engine what you want. Given you win the arguments in the chat that ensue each new feature :)
Peace, we all like what you do and it *does* help the engine. Just don't do this:
You obviously read peoples responses to me and not what my complaint was... Look back a page or so... I reiterated it and asked that the conversation not be dragged in directions I didn't intend it to go.... because like this post shows... the finger is being pointed back at me for things I didn't state.
I have no interest in my code being committed to core. Please take a minute to read it... I'll repost it here so you don't have to go find it...
@t0neg0d said:
The point I was making was lost some time ago... it has NOTHING to do with whether or not my, your, their, were work is added to core. The point was this:
User A says: Feature X that is currently in core is unusable... please fix it...
Dev B says: Nope. (no reason is given for why the broken feature isn't going to be fixed).
User A says: But it's broke.
Dev B says: No it isn't... that's by design.
User A says: WTF??! Um... here is a working version for anyone who needs it.
User X says (because that can't figure out why the feature isn't being fixed) Why isn't this being added to core??!
Dev B says: Because I can't maintain it.
Problem is, Dev B isn't maintaining there own code if it doesn't work....
Maybe this will get the convo back on track. It's been pulled in every direction but this.
EDIT: Doesn't work is too harsh... performs so poorly that it is unusable is more accurate.
EDIT: This was completely ignored, btw and the topic went back to code being added to core /boggle
