[WIP] Ale Effect Editor
-
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.
-
I don’t think I misunderstood.
Also I had not assumed that errors cannot be caused by other errors. Where did that come from?Because what I’m saying here is that in pursuit of perfectionism (while a commendable trait on its own right) there’s a case to be made where a functional yet inaccurate implementation is preferable to continuous unavailability in a struggle for accuracy. None of the existing tools out there are perfect, each has own array of bugs and features missing, that’s normal and I don’t think anyone expects them to work perfectly. I’m fairly certain DA own toolset seldom worked right if the sources to C:FW tools are of any indication of quality and stability. Besides the underlying implementation, state of its accuracy or inaccuracy at various cases, there’s also user interface, the front-end functional part of the utility is the area certainly benefiting from testing and fresh perspectives.
Like anyone else I’m eager to see new tools being made available even if they’re not perfectly behaving or accurately conveying FL’s own implementation, for practical reasons it doesn’t need to. Just like any other content authoring tools previews are at most approximations, and for most part they are good enough to be useful for content makers.
-
Ah, ok now I see what you are getting at. At first I was a little confused.
Yes, we have a quite high quality of standard, because we think as long as you are more annoyed with it than it is useful you can as well use the xml files for editing. I have tried editing effects and it is not working well enough yet (this is more Skotty’s fault as he already wrote). I have been thinking more than once about whether it would be useful as a preview, but there always have been issues so that it was not really a preview yet. But most of that is solved now. The plan was to have a look at it again soon and then try to release a somewhat usable beta. Let’s hope it’ll work!
-
I’m awaiting a Beta, it would very really awesome to have one. I’ve been using Adoxa’s XML for ages now, and made some pretty cool things. This tool could advance it to the next step
I can imagine how the preview would really streamline the whole process!
-
is the project dead or working on it?
-
I don’t have time for the OpenGL wrapper and this tool at the same time. I want to finish the wrapper first, so this is on hold until then. I have gotten a few ideas for it, though.
-
Any update on the same?
-
Topic is being updated here:
