Particles (Page 2 of 2)

Yes, this is part of the reason why I'm a bit stuck... because I feel that it's a difficult concept to explain easily. Basically, I have 3 potential solutions:
1. Keep it as it is, with the Particle Emitter owning all the data ever.
2. Separate the Particle data into a Particle Spec and have it in human writable plaintext files.
3. Separate the Particle data into a Particle Spec and create an editor environment for it.

There are pros and cons with all 3 solutions. Those being:
1. This makes the editor VERY busy with a lot of behaviour values which can, at best, distract. At work confuse. On the plus side, it's easiest to do.
2. This is an acceptable compromise, but particle editing is then less graphical which will make it less accessible.
3. This is my "ideal" solution. It defers complexity to places where most of the time you don't have to worry about it (you make a "flame" particle spec and then just apply it to any firey emitters, without caring about the values in it) but it's also the most work.

Now, regarding #3. I could make a standalone particle editor for this. I could even fork the Maratis Editor, as you said. I'm not overly keen about this. If I remake part of the Maratis environment, then why not just use the one that exists and if I don't use Maratis, it's quite likely I wouldn't get things looking exactly the same as when it comes to displaying them in Maratis.

I think I have a plan for this. I will have to think further on it though. This is by no means a finalised design. Just a concept. So if anyone feels particularly strongly about anything here, give a shout and we can discuss things. So I guess I'd best tell you the plan, right?
Well, to begin with, as I've said, my "ideal" solution is to have a separate particle editor. So, clearly I will be aiming towards that. However, the logical step would be to go through suggestion #2, but, if I know that I'm aiming for #3, it will probably change the design a bit. For one thing, having a system that can read and write the same data is important.

This also leads me onto a slightly tangential point. Much as I love the fact that Maratis has an editor, for enclosed interior scenes especially, it can be a little uncomfortable to position and edit. For this reason, something I would love to be able to do is create a plugin at a later date (potentially called MIngEd), when loaded in a project, adds a keybinding (F10 by personal preference, but that's entirely unrelated now) which will allow editing in game. Of course this will be a lot of work and a lot more design. But the point here is that I will hopefully be doing any particle editor work so that it's flexible enough to allow multiple editor interfaces fairly easily.

Anyway, that's a lot of work to do and definitely won't be done any time soon, but hopefully will explain a couple of my reasons for some of the decisions.

Not being an artist, I don't think it's fair that I suggest this... but I definitely approve of the prototyping pack or central Maratis asset repository some sort of CC license, some of them being made for Maratis specifically, some being simple exports of other CC/free models.

With regards to Vegas' comment on the particle system. I really don't think there's any risk of needing to be a maths genius to create particle specs. On the other hand, I know very well how frustrating it can be to repeatedly edit a text file, load up the game to test it, wash, rinse, repeat... I'll see how it goes. If noone's totally against it, I'll begin with it just being a plain text, probably protobuf. That way I should be able to use binaries, and serialise it nicely. We'll see how the editor stuff pans out. I would prefer to spend a little time working on my actual game

Thanks, I will look into adding something to render the behaviours in the editor. It shouldn't be an issue really.

I think you've explained the issue here. I'm making it all too complex. I have 16 variables right now and it's looking messy. I should really really be more simplistic, like having a preset system. That's sort of what I was hoping for with the particle spec stuff. I will see what I can do about reducing the complexity a bit.

Blend Swap would be a great idea. The issue is, of course, somehow, the models would have to be exported as Maratis meshes, and also normalised in size for easy use. As it's all CC, as long as you credit the original creators, it should be ok to just use without a formal agreement, but it might be best to discuss this anyway. I don't know.

I always wondered what was the best mesh size for maratis, should we take Yofrankie
source files as reference?

About the format, i really don't know what could be best :

1) Individual .mesh files : Have to assign texture path manually for each object,
Thankfully there's some batch text replacement app wich make this step very easy,
but still, that's not cool

2) .blend files : Textures have to be packed in the blend file, that mean you have to manually export textures for each object (insane ><) OR maybe there's a way to make a folder with all texture then in the .blend file, point a relative path to it?

3) Making a empty project that contain all mesh/textures in correct directories?

Ps. Nistur, i don't forget you, something draw my attention and took me some time, i should come with something by the next days

Sorry, I've been a bit busy to reply, I'm almost settled into my new flat now though.

zester: That looks great. Still definitely looking forward to seeing how this turns out.

Vegas: I think Anael said the recommended scale for models is 1 blender unit = 1m.

You can unpack all data associated with a blend file in one go. I can't actually remember where I found this option.

To be honest, though. I think it's easier if all models were created in an open standard which any 3D editor can open, say obj or dae. What I've been doing is putting obj files in art/, textures in maps/ and exported meshes in meshs/. Doing it like this makes the relative paths to a texture the same (../maps/sometexture.tga).

If we're still talking about the particle example application. I would like to structure it nicely, I'm not _entirely_ sure how I'm going to manage this, but I think that each "level" should be in it's own directory with all assets there, and anything common also separately. Not that it makes any difference to how Maratis loads things, it's just much clearer if someone was looking for how things are put together.

I wouldn't worry about any of this though, when I have time to create a demo application, I can structure this around anything provided.

Also, as I've said, I've recently moved, so I've not been able to do anything really, so I really can't judge people on not responding Especially as this isn't their project

Here's some tests (only diffuse textures, very basic stuff/unfinished for most)
In order :
(1) Bathroom (smoke on top of the bath) / (2) Fire in barrel
(3) Waterfall (water coming from the top) / (4) Waterfall
(5) Fire in barrel / (6) Smoke coming from the pipes
(7) Dont know wtf is this

I'm missing stuff to do some complete 3d scenes however i'm gonna try that next,
if there's an environment you like more than the others, just tell !

Hi vegas and thx for  showing this, but Im not seeing any particles in any of the embedded pictures.

cheers
nl

I think you could have been nicer about it, but I get the point now.
Or maybe its just the (dutch, french or german) way of speaking about such issues.

You could have just said: They are just examples for what will be used to showcase particles , and left it at that

cheers
gm

Last edited by VeganDev (2012-05-12 00:41:11)

Ok fair enough, I did wonder given the possible language barrier.Stuff happens

cheers
gm