@t0neg0d said: Sorry, been a bit busy today... running errands and such. Maybe this will give you a better idea of what I mean no need to write script, you just use the interface:
I Love IT!!! and I LOVE YOU!!!
1 Like
@abies
Just a quick note to let you know that I believe the save/load project should be complete in the next day or so. It’s a lot of data to go through, as it has to save multiple emitter/data structures + the script engine stuff. But, proof of concept worked for creating/writing the per project xml files and displaying a list of saved projects + loading up the list of emitters for the selected project and creating a default emitter for each with the saved emitter name.
Now, just gobs and gobs and gobs of data to structure into XML.
Just an update on the status of the save/load project feature:
What’s done:
-
Save function is complete, including:
** Per project save files
** Test Scene & Camera info
** All Emitters/Properties/Influencers
** Sequencing Scripts -
Load function is getting there
** Test Scene & Camera info - Complete
** All Emitters/Properties/Influencers - About half way done - There is a lot involved here.
** Sequencing Scripts - Not there yet
Anyways, just throwing the update out here, because I was worried initially that it would take longer to implement than the target date I set for releasing this. This is obviously not going to be the case, as I am hoping to have it (EDIT: It being the save/load project feature) finished up tonight or early tomorrow.
1 Like
So to get this straight… You save “particle projects” in some xml format and to use the particles you create code that you paste into classes in your project?
@normen said: So to get this straight.. You save "particle projects" in some xml format and to use the particles you create code that you paste into classes in your project?
I’m almost scared to answer you, because I’m fairly sure you’re baiting me… but… I’ll bite.
Yes & yes… it allows you to design and sequence multiple particle emitters over a time frame. It does save the projects this way, because outputting the projects as a j3o would be semi useless considering.
The interface is a bit more than a toolbar of hard to understand buttons, (me not knowing how to write this as an SDK plugin aside).
So, all in all, I think this was the best way to go about it.
Knowing that you will likely not download the required jar files and try it out, you’ll have to take my word for it. Or maybe someone else who does use it can explain a bit better than I.
Actually may as well continue explaining why j3o output would be semi useless.
Who in their right mind would save 6 sequenced particle emitters to a format that can’t store any of the relative code to make them execute their sequence of events?
Also, the emitters use influencers, which can be cloned, modified, reused for multiple emitters. Saving the emitter would be like saving a individual copy of Sonar with every song you record.
EDIT: The code output is to teach you how to use the particle emitter without having to read through a 600 page wiki
- Visually design
- View the code you would have written --or-- use it.
This project also has the added benefit of showing you how to build a very complex UI using tonegodGUI. The project has taken me a little over a week to produce so far… and not a single second was spent trying to figure out how to register some action listener to some control that didn’t show up a screen controller that consumes events I needed to go to the app 
@t0neg0d said: It does save the projects this way, because outputting the projects as a j3o would be semi useless considering.I don't want to start a flame war, but I'd like to know why you feel like saving it as j3o would be useless? It would avoid the second part "generating code to have my particle emitter to work".
@t0neg0d said: I'm almost scared to answer you, because I'm fairly sure you're baiting me... but... I'll bite.Yes & yes… it allows you to design and sequence multiple particle emitters over a time frame. It does save the projects this way, because outputting the projects as a j3o would be semi useless considering.
The interface is a bit more than a toolbar of hard to understand buttons, (me not knowing how to write this as an SDK plugin aside).
So, all in all, I think this was the best way to go about it.
Knowing that you will likely not download the required jar files and try it out, you’ll have to take my word for it. Or maybe someone else who does use it can explain a bit better than I.
@t0neg0d said: Actually may as well continue explaining why j3o output would be semi useless.Yeah, well... I just wanted to know what the intended workflow would be when using this. :roll: Doing an SDK plugin for this would be trivial, also with the scripting stuff like in your UI, I don't know what you want to say with the toolbar comment though.Who in their right mind would save 6 sequenced particle emitters to a format that can’t store any of the relative code to make them execute their sequence of events?
Also, the emitters use influencers, which can be cloned, modified, reused for multiple emitters. Saving the emitter would be like saving a individual copy of Sonar with every song you record.
Sure having a class with code for each effect works, personally I don’t really like generated code for design elements though. But it obviously saves on complexity of the core library code, given that you store things like execution time in code and not in some properties of the library objects (e.g. cinematic system).
You don’t seem to understand that the SDK has no “particle editor”, particle editing in the SDK is just being able to edit Spatials and Controls bean properties, theres no additional logic for “particle editing”. But I guess you somehow thought I would use the mighty power of our particle system and editor (lol?) to bash your library, as you should naturally expect me to. :hitler:
@nehon said: I don't want to start a flame war, but I'd like to know why you feel like saving it as j3o would be useless? It would avoid the second part "generating code to have my particle emitter to work".
IMHO, the only confusion with j3o is saving materials inside of it. It becomes dificult to change materials after saving j3o.
@mifth said: IMHO, the only confusion with j3o is saving materials inside of it. It becomes dificult to change materials after saving j3o.
OT post is OT. Just make a j3m.
@normen said: Yeah, well... I just wanted to know what the intended workflow would be when using this. :roll: Doing an SDK plugin for this would be trivial, also with the scripting stuff like in your UI, I don't know what you want to say with the toolbar comment though.Sure having a class with code for each effect works, personally I don’t really like generated code for design elements though. But it obviously saves on complexity of the core library code, given that you store things like execution time in code and not in some properties of the library objects (e.g. cinematic system).
You don’t seem to understand that the SDK has no “particle editor”, particle editing in the SDK is just being able to edit Spatials and Controls bean properties, theres no additional logic for “particle editing”. But I guess you somehow thought I would use the mighty power of our particle system and editor (lol?) to bash your library, as you should naturally expect me to. :hitler:
Yeah, I’m aware of the lack of an editor and I didn’t think you were going to bash me over the head with it even if it did exist =)
One of the reasons I outputted code instead of saving the final output to a JME cobject was consideration in design concepts for how to manage effects in a game and not wanting to give someone the impression that handling them in that fashion would be best… when in all reality, an ideal fx system would consist of configuration definitions for influencer chains and an emitter pooling system. But, that is specific to the project your working on, etc
@nehon said: I don't want to start a flame war, but I'd like to know why you feel like saving it as j3o would be useless? It would avoid the second part "generating code to have my particle emitter to work".
Sorry, I missed your post. The post above this explains my reasoning. It’s not useless… just teaches someone a really bad design concept for how to manage effects for your game.
I would suggest looking into what tonegod has prepared hands-on before going further with critique of the possible design decisions.
Which leads to real question - when ?
@abies said: I would suggest looking into what tonegod has prepared hands-on before going further with critique of the possible design decisions.Which leads to real question - when ?
Who’s criticizing? I guess I’m not even allowed to ask questions anymore around here.
@t0neg0d said: Who in their right mind would save 6 sequenced particle emitters to a format that can't store any of the relative code to make them execute their sequence of events?Did you consider using a control?
@abies said: I would suggest looking into what tonegod has prepared hands-on before going further with critique of the possible design decisions.Which leads to real question - when ?
Well… I’m still a ways from completing it, but if your willing to put up with knowing that it will need to be updated and is not final, I’ll get the latest builds together for the ui library, emitter and deigner and have the available for download by tomorrow. It would be nice to get some feedback as I’m working on it.
@nehon said: Did you consider using a control?
Actually, for this instance, I didn’t… but! Since the initial output is not the only option I wanted to give… I’ll try this next.
Since I’m not quite sure how this will work, I would, create an instance of the control, feed it a bazillion whatevers (emitters w/ influencers, etc) and then save this via the standard JME save output capsule, correct? Which in turn calls save on all child savables?
If this is the case, I’ll add this as a way of outputting the final to a usable format… however… I still think that it would be better if someone designed an FX pooling system for themselves
The biggest question I have, is concerning how save is called… say for instance I had a SafeArrayList of emitter and saved the control and defined the array as part of the output. Would this in turn call save on object store in the array?
You can only store lists of other Savables or primitives, so basically yes.
1 Like
@abies
Ok… if your willing to put up with the following outstanding issues, I’ll put this up for download tomorrow.
- Particle Mesh Types are not complete in the builder. Only Quad, JME Primitives & Impostor are currently working & I’m not generating textcoords for the primitives, so they are only useful as emitter shapes.
- Code output isn’t complete, as much was added after I put it together.
- The emitter class’s save needs to be updated, as well as clone… the influencers are all up to date, however the emitter is not.
If you don’t mind working around these while I’m finishing it up, I’d love to get this out in peoples hands and start getting some feedback from actually using it.