@t0neg0d Y U NO HAVE PLUGIN?!? 
Heheh
Given your general output so far, I’m surprised you don’t have 50 plug-ins in that list.
I’m working on three different ones and can’t even get them finished enough to post about.
Given your general output so far, I’m surprised you don’t have 50 plug-ins in that list.
I’m working on three different ones and can’t even get them finished enough to post about.
How well does the plugin thing work for “feature libraries” as opposed to stuff that actually adds features into the SDK? I have to admit I’d sort of assumed it was for the latter rather than the former.
@t0neg0d said:
My SSAO filter - It uses nothing past OpenGL 1, it performs 2x as well as the current SSAO filter and produces results that are more accurate (at least look better) then JME's current SSAO. I set it up to be like the BasicShadow renderer... a simple option for users who can't use JME's SSAO due to the fact that it is a resource pig that can up to half your frame rate for visual results that don't really look good (no offense intended here... nehon's work is close to godliness, and something I strive towards achieving). However, instead of considering adding mine as a Basic version of SSAO... it is going to be picked through for ideas to fix the current.
OK....now you won't get away with this...
We core members are committed to this project without condition, and there is not a day where i don't work on JME one way or another.
We MAINTAIN this engine what ever it takes.
You're around here since what? a year, right? During this year you went AWOL during like 3 month, because you have a life and many other things to do...Of course that's normal.
Now if I add blindly your code to the core, without review, what's gonna happen next time an issue occur with it? Are you gonna step in? in a month? in a year?
Sure thing is that if you don't I'll have to....and if i have to crawl into some code to fix issues, i'd rather it'd be mine or at least that i took the time to take the grasp on it before integrate it.
Damn it, who's ego driven seriously?
@zarch said:
How well does the plugin thing work for "feature libraries" as opposed to stuff that actually adds features into the SDK? I have to admit I'd sort of assumed it was for the latter rather than the former.
You can use it for either. For example, looking at the above list, I'm 99% sure MirrorMonkey is not an SDK plug-in but an add-on library. There are also several file format libs that don't have SDK involvement.
None of the things I want to contribute as plug-ins (so far) have any SDK ties.
I really like the fog filter and have on my todo to get a more dynamic sky than the engine-skybox in my game. But I agree with pspeed, the community should be more of a bazaar of plugins and additions and the engine could do with loosing some weight
The SDK (Netbeans) module system is one battle tested framework for enabling a bazaar of modules. The only drawback is that it more or less forces you to use the SDK to build and package your game. Personally I have no problem with that even if I can go on record saying I loath the netbeans build system, it is an arcane piece of cr*p. But I can see the advantages it gives and I think they outweight the drawbacks.
So I’d love to help getting the fog filter (and the sky) packaged as an SDK plug-in if you’d like. But as a matter of personal ethics I don’t use or change code that lacks a license header. So could you please just tack some license (the new BSD is preferred I guess) on the source or at least say that you license your work in some manner?
@nehon said:
OK....now you won't get away with this...
We core members are committed to this project without condition, and there is not a day where i don't work on JME one way or another.
We MAINTAIN this engine what ever it takes.
You're around here since what? a year, right? During this year you went AWOL during like 3 month, because you have a life and many other things to do...Of course that's normal.
Now if I add blindly your code to the core, without review, what's gonna happen next time an issue occur with it? Are you gonna step in? in a month? in a year?
Sure thing is that if you don't I'll have to....and if i have to crawl into some code to fix issues, i'd rather it'd be mine or at least that i took the time to take the grasp on it before integrate it.
Damn it, who's ego driven seriously?
Yes, your ongoing commitment to this engine is critical... I not only get that, but appreciate it. Life happened with me and I had no commitment here so this was what took the hit. On the other hand, I take my commitments very seriously and if I contribute code to something, I maintain it for as long as it's needed... or at least until I stop breathing. That aside, I'm not concerned with whether or not my version of the code is used, I am, however, concerned with whether or not the core reasons for make the changes will be overlooked if integrated into the original.
The question was directly asked, "Are you planning on adding this to core?". You responded to them with, "I'm not comfortable adding the code as is..." (?? no reason why... if you told me the issues you have, I could fix them or explain why they are that way to begin with, not to mention... I am not opposed to documentation) "I'll probably just integrate the ideas to make the existing perform better."
I'm not sure that is possible without ditching half the code (most importantly the convolution filter). And since you are planning on rewriting the SSAO filter anyway, why not add this as an option as is? The filter itself, is based off of yours... if you look at it, you can see that plainly. The shaders are based off of yours... if you look at them you can easily see this as I didn't change the names of methods... just changed the approach to texture sampling and used an older (well known, though slightly modified) method of blurring.
@pspeed said:
@t0neg0d Y U NO HAVE PLUGIN?!? :) Heheh
Given your general output so far, I'm surprised you don't have 50 plug-ins in that list. :)
I'm working on three different ones and can't even get them finished enough to post about.
I'm definitely going to do this... I've never been opposed to it. I took the other approach for the reason I stated earlier :)
@jmaasing said:
I really like the fog filter and have on my todo to get a more dynamic sky than the engine-skybox in my game. But I agree with pspeed, the community should be more of a bazaar of plugins and additions and the engine could do with loosing some weight :)
The SDK (Netbeans) module system is one battle tested framework for enabling a bazaar of modules. The only drawback is that it more or less forces you to use the SDK to build and package your game. Personally I have no problem with that even if I can go on record saying I loath the netbeans build system, it is an arcane piece of cr*p. But I can see the advantages it gives and I think they outweight the drawbacks.
So I'd love to help getting the fog filter (and the sky) packaged as an SDK plug-in if you'd like. But as a matter of personal ethics I don't use or change code that lacks a license header. So could you please just tack some license (the new BSD is preferred I guess) on the source or at least say that you license your work in some manner?
Sorry for this. I certainly will. The reason I never bothered is I try to post the code with the @author info removed, so this isn't an issue to begin with. Sometimes I forget to remove that :( I'll just add the new BSD to the top of the classes. And I would appreciate any help in this! :)
@nehon Somehow I think this was glanced over
@t0neg0d said:
(no offense intended here... nehon's work is close to godliness, and something I strive towards achieving).
I didn't say this to kiss your ass... It's the truth.
@t0neg0d said:
The question was directly asked, "Are you planning on adding this to core?". You responded to them with, "I'm not comfortable adding the code as is..." (?? no reason why... if you told me the issues you have, I could fix them or explain why they are that way to begin with, not to mention... I am not opposed to documentation) "I'll probably just integrate the ideas to make the existing perform better."
Well if you want me to explain why I said that lets go.
First, i never looked into your code in details, for anything that you posted in the forum. Always looked at the result though and you do have talent to make things pretty.
But, according to some discussion we had, i don't trust your code. At least not until i'll look into it in details.
Especially the discussion about the computation of the center of the frustra in the shadowRenderer,
You look like the kind that change a variable value here and there to see if that looks better. From experience this kind of coding leads to maintenance nightmare.
Now that's just an impression and I may be wrong, and I don't say your SSAO code is bad because I did not looked into it in details. And once I'll have a complete review/test of it, i may decide to integrate it as is if it's solid.
Also i'm a bit skeptical about the results. You say it looks better, I say it looks exactly how the first SSAO I posted on this forum looked. I'm not saying this because I'm ego driven, but because I don't like it.
The first SSAO had no random sampling, no convolution pass, was performing twice better, and looked exactly like yours. If you used a wide sample radius you had those ridiculous bandings that were ruining the effect. So the Filter was looking good enough with a low radius making it look more like an outline....
That's the very reason I decided to change it. I added random sampling and bilateral blurring and IMO it looks better, but not yet good enough and very slower. (hence the MSSAO thing I told you about).
But since i don't have universal taste and that you seem to appreciate the look of yours, others may be in the same case. That's why I considered adding yours to the core. But in the end It'll be faster to revert the last changes I did, because i'm pretty sure it won't be very far from your SSAO version.
Now about integrating stuff into the core in general. We try to make the engine consistent in it's behavior and API, we don't want it to look like a patchwork. We can't take every contribution and just ditch it in the core because it "looks good". And since I'm here there was absolutely no contribution that make it in without modifications.
So when being constantly asked "Is this going to be core" by users, i'd rather be cautious and say "maybe".
1 Like
@nehon said:
Well if you want me to explain why I said that lets go.
First, i never looked into your code in details, for anything that you posted in the forum. Always looked at the result though and you do have talent to make things pretty.
But, according to some discussion we had, i don't trust your code. At least not until i'll look into it in details.
Especially the discussion about the computation of the center of the frustra in the shadowRenderer,
You look like the kind that change a variable value here and there to see if that looks better. From experience this kind of coding leads to maintenance nightmare.
Now that's just an impression and I may be wrong, and I don't say your SSAO code is bad because I did not looked into it in details. And once I'll have a complete review/test of it, i may decide to integrate it as is if it's solid.
Also i'm a bit skeptical about the results. You say it looks better, I say it looks exactly how the first SSAO I posted on this forum looked. I'm not saying this because I'm ego driven, but because I don't like it.
The first SSAO had no random sampling, no convolution pass, was performing twice better, and looked exactly like yours. If you used a wide sample radius you had those ridiculous bandings that were ruining the effect. So the Filter was looking good enough with a low radius making it look more like an outline....
That's the very reason I decided to change it. I added random sampling and bilateral blurring and IMO it looks better, but not yet good enough and very slower. (hence the MSSAO thing I told you about).
But since i don't have universal taste and that you seem to appreciate the look of yours, others may be in the same case. That's why I considered adding yours to the core. But in the end It'll be faster to revert the last changes I did, because i'm pretty sure it won't be very far from your SSAO version.
Now about integrating stuff into the core in general. We try to make the engine consistent in it's behavior and API, we don't want it to look like a patchwork. We can't take every contribution and just ditch it in the core because it "looks good". And since I'm here there was absolutely no contribution that make it in without modifications.
So when being constantly asked "Is this going to be core" by users, i'd rather be cautious and say "maybe".
1) I appreciate your honesty.
2) This is sad. You completely missed the topic at hand because you got offended that I called your baby ugly. Which, I hate to be the barer of bad news... it goes one step beyond ugly... it's ugly and broken.
3) I think I'm pretty much done sharing the work I do
1 Like
As one of the people who’s been on the wrong side of this I actually agree with a fair amount (although not all) of what has been said about this issue by the core devs. What is going into core needs to be known, necessary and maintainable. You cannot rely on contributors to maintain their code (and I’m sorry if you are one of the reliable people - but we all know not everyone is) - and once it’s in core it does need to be maintained.
I think the contribution repository is a really big step in the right direction though as it allows things like these shaders to be contributed and distributed in a known way without requiring them to go into core.
For example: http://hub.jmonkeyengine.org/groups/general/forum/topic/rumour-shaderblow-wil-be-moved-to-the-official-jme-contribution-repository
I think the imbalance here may even be that some of the shaders/shadow/etc stuff that is current in core actually should be in contributions - rather than the fact that some of these contributions should be in core.
Guys, just don’t make a war please! Just make a fork if you have some other thoughts.
Peace!
1 Like
Actually i don’t really get where the problem is.
Changes which do not actually need changing the core files could be easily added to a contribution plugin. Since Filters, effects and shaders do not actually need to change a single line i see no reason in adding them to the core. From my point of view, even the current filters added to the core should get removed and shipped as a plugin. In that way it would decease the size of the base library and every user can simply add stuff they need.
Then every user who wants to use SSAO for example need to look in the contribs, and can choose between different version of user managed stuff.
From my point of view making more use of the contribution plugin system (and fixing the line what’s in the core and whats not) would have solves the current issue with t0neg0d and zarch…
//add
The worst thing that can happen is that contributors stop contributing because their work does not get added to the core. And i can understand them if nearly the same feature get’s added to the core a bit later they feel offended. By offshoring all things not belonging to the core that would not be a problem anymore… AFIAK
@t0neg0d said:
3) I think I'm pretty much done sharing the work I do
noooooo, ur work is awesome! <3
I think I’m pretty much done sharing the work I do
you know that I appreciate your awesome work :)
Myself i shared with EasyFind and MotiveAI projects.
I also always wanted to make a deal with someone to make sharing space(for example google code) and help each other with smaller projects(pathfindings/shaders/code/even graphic).
As i noticed, people usually share with 1-3 projects Max, because later they notice, that they have no more satisfaction from that.(or maybe there is other reason)
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.
To Plugins! The cause and solution to all of life’s problems.
this is very similar to “getPixel” topic, really.
edit: yeah, plugins could be best way to solve it.