[WIP] Ale Effect Editor
-
Well hey if I can get that renderer compiled on multiple OSs and not have it trample my GL state, it’d be great
-
I can precompile it for you. It’s written with freepascal / lazarus so it is not really os dependent. Please understand that we don’t plan to release the source as we would gain no benefit from it.
As for the states: You would have to set your vertex attrib arrays again and the blending modes. That should be all (at least at the current state). And of course different shaders are used.
-
Thanks!
The main benefit is not having to worry about releasing the code
Meaning license, clean up and copyright stuff (since this would require our real names, which we are not really fond of to publish - and without them we would not be the authors since everyone can claim a nickname).Basically from our point of view it would mean to invest more time which can better be spent implementing more things.
-
Being a mainly linux user and open source developer my opinion here maybe biased but….
Everything I’ve ever written and released (not just FL but other projects) I’ve never once felt the need to use my real name, and used the GNU/GPL license.
You dont need to actually have a copyright registered, in fact most open source projects dont (since their written by multiple random collections of people). Firefox is one such project, only the name is a registered trademark.
If your worried you might have to legally prove authorship one day theres lots of ways to do so, one simple way would be archive multiple copies of the source to several major email providers before the release date, its hard to fake those timestamps.
The real advantage of releasing the code comes when you’ve decided to move onto other projects, the community can update it or fix bugs, and interested people can also help with the code cleanup if thats needed.
Which ever route you decide on though, open or closed, I’m eagerly awaiting the release it looks great!
-
Thanks! And also thanks for the advice. In case we don’t decide to develop it any further making it open source is definitely very likely to happen. But for the time being we like to finish what we can do first. Maybe you can give us some further advice when the time comes, that would be very helpful.
-
I’ll beta test what you compiled already, PM me a dropbox link, I’ll let you in on some bugs, crash-inducing or otherwise.
-
Sorry, at the moment we know most of the bugs. When the time is right there will be a beta for everyone.
Currently I am working on this project again anyway, so only some progress has been made.
-
Schmackbolzen, any update? I know your working on your opengl, just wondering if this has been put on back burner for now? I am still looking to test this out
-
Actually it is mostly my fault. Recently I am playing too many other games and am busy with university stuff. And since I’m pretty much responsible for the UI, I delay it by not being motivated at all to work on it.
-
Understandable, I’ve been alpha cloning on Eve lol. I don’t find it as pop in and have fun like freelancer. I hope you do find some motivation for this, as like I said I’m looking forward to it. If you need testers for it, I will give it some testing.
-
I have been working from time to time on the particle system and even recently solved our GUI problem by using html for all the dynamically generated inputs (Lazarus has a really nice component for this), but as Skotty pointed out I was not able to motivate him using it.
The last thing I started working on was cleaning the code up and optimize it using Data Oriented Design, so that it gets faster by being more cache friendly (although we already can simulate more than 10000 particles without problems).
There still is a problem with multiple fields behaving not the same like in FL. Beams need to be rendered different, so that they look similar. Also there are values which are not supported yet. But the really tough things are done I think.
Currently I am writing the normal, tangent and binormal calculation algorithm for the OpenGL project, so as you already pointed out I am still more focused on getting that project done.
-
If I could, what needs work? My knowledge on scripting code is nill to none, but I am willing to learn. Maybe point me in the right direction to start, as I do like to learn new things. Then maybe, just maybe give a hand after learning.
-
Actually this is really heavy stuff. Especially the math is quite tricky at some points. With all those node transforms I had to reformulate the problem to make it fast enough for all this calculations per particle. Also there is lots vector math.
I think the best way one could help is figuring out the meaning of the missing parameters. But you would need to use adoxa’s xml tools to generate the ale effect and try to make sense of changes you do. The problem is that this is not easy and some stuff you only can figure out with lots of experience or being able to test ideas in an implementation. This is why I hesitated asking people for now. For some really tricky things I even used my OpenGL wrapper to let FL render effects in wireframe mode because otherwise it was impossible to figure out what’s going on.
When the most difficult parts are solved I plan to ask people for testing and maybe even release a beta where people can try to figure out the missing values by observing the effects in FL, but we are not there yet
-
I’ll mess with adoxa’s tool this weekend. I do understand some of treewyrm’s documentation and see what i can come up with. I know your more focused on your opengl project, but I am hoping you and skotty do continue on this as I do believe you have more then myself hoping for a beta. Many thanks on what you guys have come up with so far, cheers.
-
Thanks! I had a look again at the fields and since I solved the mystery about the approach value the last time I am not sure whether there actually still is a problem with the fields. I’ll try to let you know until the weekend. I also will go through the document again to see if there have been any changes.
Last time I checked treewyrm had errors in the documentation. If we have the time and are sure enough it is not our mistake we will correct them.
One thing which is still a tough problem is the randomness of the emitters. If you do a naive implementation and use the frequency you will get an absolute deterministic behaviour, meaning your e.g. engine flame will flicker in always the same way (Example: 1,1,1,2,1,1,1,2, … particles per time step) . But this is not like FL behaves. It is what I was working on the last time when I was trying to figure out stuff.
-
That being said the work on it would have been faster if I actually had the access to whatever unfinished build you had of the editor, alas at the current state of things the likelihood of editor coming out in any form is… well, somewhere too unreasonably far away.
-
I am not sure I follow. I knew which flaws there were left and I did solve most of the difficult problems. There are not many left to solve. Why would I let someone test software for errors I already know?
It might be difficult to understand for some, but my opinion is like the old saying “too many cooks spoil the broth”.
When I had difficult problems I did ask you. In the end I found a solution and I think you underestimate the work that is already done. Also keep in mind that we still are taking lectures at university and thus they take precedence (although I am finished soon).
Taking breaks from the code allows me to rethink certain problems and start with a fresh mind again. This is actually the reason why I work on many projects in parallel and for now this has worked out very well. Although it takes more time. But it is a hobby, isn’t it?
P.S.:
In order to guard against misunderstandings: We did not use your ale document. We already had reversed more of the ale stuff. When we are finished we plan to document any differences of our implementation, which hopefully will behave like FL. But it was good that you started it, so it is not so much work anymore to document all the stuff. -
Docs are for everyone to learn and use however they see fit. Feedback is welcome and errors should be fixed so if you know them why not point out so I can fix them? Knowledge empowers others to do, so that other modders don’t have to do same research over and over again all on their own. There’s no point or practical benefit to anyone in keeping their findings in closets. Formats, structures, behaviors, utilities and codes, the more there is known and available to everyone the better it is for everyone involved.
Don’t get me wrong, I’m glad you’re still working on it. It’s just from the conversations back then and as the time went by it all left me quite skeptical of it ever being released for anyone left around to make a good use of.
Would it be prudent to say the point of others testing is to find errors that you don’t know yet, hmm…
-
I think you misunderstood: As long as we are not sure our implementation is correct it does not make sense to “correct” anything. It can very well be that we make it worse.
Addition after I read your edit:
Regarding the errors: You are assuming that errors are not caused by other errors. This is often not true. In fact most of the time when I changed the implementation other errors vanished as well. I don’t want to waste time looking for things which are just a side effect. And there have been a lot unexpected ones.
I want to reach at least a state where I can say that the implementation is as close as I could get it to FL (otherwise you are constructing effects which don’t look the same) and it only has minor errors we can fix after a beta release. The problem with the fields and random behaviour of the emitters are basically the kind I want to have gone because they cause other stuff to not work correctly. There are not many of such errors left, so it should not take that long anymore.
