[youtube]fmZmRlYS6lY[/youtube]
I made this vid for the next question, i made this particle shit thing and its supposed to be a circle, i see lots of em along the x and y axis is that good for a normal circle? im using sin and cos, and i think that makes those clutters?
particles
-
Shadow
- Masterful
- Posts: 743
- Joined: Tue Jan 29, 2008 12:00 am
- Personal rank: Mad Carpenter
- Location: Germany
- Contact:
Re: particles
I see no video, or is it just me?
So you're trying to code your own... particle emitter(s) ?
So you're trying to code your own... particle emitter(s) ?
Re: particles
Oh hm im in bed now on my phone ill add the vid tomorrow then. And its just spawning rising sprites like rev has on angeldust. Only in the vid they have no velocity and a lifespan of 1000 pure for testing reasons. To see whether its a circle its spawning in or not.
-
Feralidragon
- Godlike
- Posts: 5493
- Joined: Wed Feb 27, 2008 6:24 pm
- Personal rank: Work In Progress
- Location: Liandri
Re: particles
Fixed video.
Regarding the circle math, that's not done properlly. Just a question: are you converting whatever angle unit (uu or degrees) to radians? Generally that's the problem.
Btw, it's NOT a bad idea spawning particles using actors, as long as those particles don't exceed a certain number, but for a normal regular usage, well yes, I agree with Shadow.
There are some ways to do lots of particles with a good speed:
- native coding (c++): there's nothing faster and as flexible, but it would run only in some computers and not all;
- Canvas: with some 3D to 2D math on it (I think, although Shadow knows this one much better since he has been working heavilly on canvas);
- You are be able to spawn dozens and even hundreds of fast particles using UScript, without any canvas usage or some advanced math functions, and just by using nothing more than 1 to 5 actors, using vertex meshes with bParticles=True
No, this is not one of those silly jokes, is actually what I use the most: I want a certain particle effect, which will be allways the same, so I make a model, place the vertexes where I want the particles to be, animate the whole thing accordingly, import and voilá. And when you use "hybrids" (vertex meshes with normal models/meshes), you can do some UT2004 and even UT3 like particle effects. Of course, this takes some work to do, but the final results and performance really make up to it, and as long I want a stable particles animation, this is the method I use.
I only use "actors" as particles from stuff affected by the world physics (velocity, gravity, etc), but generally I never spawn more than 10 at once, and nowadays I try to make the work rely mostly on the client (when I add multiplayer support), so things flow nicelly.
Sometimes I use stable particles animation with some physics like gravity, when well done you can make 100 more particles fall at aparent different speeds using 1 single actor with PHYS_Falling and with the proper animation (I did this for my tank yet to be released, and it looks good enough, the particles I mean).
Waffnuffy (from unrealsp, EXU) uses actors to spawn hundreds of particles though, and the performance drop is not that great to stop to use them, but again, I agree with Shadow on this: actors for particles - avoid using them in that sense of the word if possible.
Regarding the circle math, that's not done properlly. Just a question: are you converting whatever angle unit (uu or degrees) to radians? Generally that's the problem.
Btw, it's NOT a bad idea spawning particles using actors, as long as those particles don't exceed a certain number, but for a normal regular usage, well yes, I agree with Shadow.
There are some ways to do lots of particles with a good speed:
- native coding (c++): there's nothing faster and as flexible, but it would run only in some computers and not all;
- Canvas: with some 3D to 2D math on it (I think, although Shadow knows this one much better since he has been working heavilly on canvas);
- You are be able to spawn dozens and even hundreds of fast particles using UScript, without any canvas usage or some advanced math functions, and just by using nothing more than 1 to 5 actors, using vertex meshes with bParticles=True
No, this is not one of those silly jokes, is actually what I use the most: I want a certain particle effect, which will be allways the same, so I make a model, place the vertexes where I want the particles to be, animate the whole thing accordingly, import and voilá. And when you use "hybrids" (vertex meshes with normal models/meshes), you can do some UT2004 and even UT3 like particle effects. Of course, this takes some work to do, but the final results and performance really make up to it, and as long I want a stable particles animation, this is the method I use.I only use "actors" as particles from stuff affected by the world physics (velocity, gravity, etc), but generally I never spawn more than 10 at once, and nowadays I try to make the work rely mostly on the client (when I add multiplayer support), so things flow nicelly.
Sometimes I use stable particles animation with some physics like gravity, when well done you can make 100 more particles fall at aparent different speeds using 1 single actor with PHYS_Falling and with the proper animation (I did this for my tank yet to be released, and it looks good enough, the particles I mean).
Waffnuffy (from unrealsp, EXU) uses actors to spawn hundreds of particles though, and the performance drop is not that great to stop to use them, but again, I agree with Shadow on this: actors for particles - avoid using them in that sense of the word if possible.
-
Shadow
- Masterful
- Posts: 743
- Joined: Tue Jan 29, 2008 12:00 am
- Personal rank: Mad Carpenter
- Location: Germany
- Contact:
Re: particles
Well, really. It IS indeed a bad idea creating a particle system with actors. Luckily I had the chance to look upon a more or less current version of ULevel->SpawnActor Function in C++ once and there's shit load going on there:
1. The function makes some low-level checks (is there a levelinfo, is the class correct, is it static, is it abtract etc.)
2. Then it checks initial placement and collision
3. Actor linkage and initial setup (tagging, location, rotation, owner, instigator)
4. After that components and volumes / zones are passed to that new actor (components / volumes don't apply in this case)
5. After ALL that uscript for this actor is initialized (spawned(), prebeginplay() and beginplay() are called)
6. Components are checked and updated (doesn't apply here)
7. Zone is set, enchrochment check, postbeginplay and initialstate are called
8. A new FActorLink is created and postnetbeginplay() is called
9. The new actor is returned
Even the destroy function is as long as this Oo
So...
- Native coding is the only suitable solution programming an own particle engine, really.
- Canvas might come in handy, but please note that there're no ZBuffer checks for this, as epic was so kind leaving out passing ZDepthBuffer for the UScript versions of the canvas functions (which has a good reason), any sprite you see is drawn and maintained by the canvas as it's powerful in c++, on uscript level it's only a good solution for HUD, GUI or some simple graphics rendering
- Vertex particles only apply on a suitable meshes, if you want distinct particles, vertex particles fail, again even this is rendered by the Canvas in C++
I already missed a constructive disussion about particle engines here for a long time!
1. The function makes some low-level checks (is there a levelinfo, is the class correct, is it static, is it abtract etc.)
2. Then it checks initial placement and collision
3. Actor linkage and initial setup (tagging, location, rotation, owner, instigator)
4. After that components and volumes / zones are passed to that new actor (components / volumes don't apply in this case)
5. After ALL that uscript for this actor is initialized (spawned(), prebeginplay() and beginplay() are called)
6. Components are checked and updated (doesn't apply here)
7. Zone is set, enchrochment check, postbeginplay and initialstate are called
8. A new FActorLink is created and postnetbeginplay() is called
9. The new actor is returned
Even the destroy function is as long as this Oo
So...
- Native coding is the only suitable solution programming an own particle engine, really.
- Canvas might come in handy, but please note that there're no ZBuffer checks for this, as epic was so kind leaving out passing ZDepthBuffer for the UScript versions of the canvas functions (which has a good reason), any sprite you see is drawn and maintained by the canvas as it's powerful in c++, on uscript level it's only a good solution for HUD, GUI or some simple graphics rendering
- Vertex particles only apply on a suitable meshes, if you want distinct particles, vertex particles fail, again even this is rendered by the Canvas in C++
I already missed a constructive disussion about particle engines here for a long time!
-
Feralidragon
- Godlike
- Posts: 5493
- Joined: Wed Feb 27, 2008 6:24 pm
- Personal rank: Work In Progress
- Location: Liandri
Re: particles
But well, there are huge problems with native: it will only run in some systems (Windows, some Linux with Wine, idk about Mac), when not done properlly it may crash in much uglier way than a regular UT crash (correct me if I'm wrong), and unless you do an installer like the one Antrax made for ACE, people won't be able to use it at all on servers (most people download the stuff from the server, so...), and this only thinking on the final user.
When thinking in the developer, there are even more problems: you have to setup a proper development environment with the proper files (with UScript you don't have that trouble, it just takes Notepad++ with a plugin, UMake and you are ready to go), and if you do something wrong, strange things may happen.
C++ as a language is one of the most powerfull ones, but also one of the hardest to learn relative other languages. People used to ECMAScript based languages (JavaScript, UScript, ActionScript, WhateverScript), will have a hard time to understand how things work out. Only people working heavilly in ActionScript, JavaScript and PHP for instance, won't have such big difficulty though, since PHP is a crappy language to start with (a very strange and unique one), so people will be used to "differences", and PHP itself has some things very close to C++ syntax wise (the use of "->" to references instead of the usual "." in ECMAScript languages for instance), and with JavaScript and ActionScript you complement with object oriented programming and further coding knowledge, from here UScript is as easy as to breath (as a language) and C++ will have a much smaller level of difficulty.
But either ways, someone just used to UScript, won't be able to do a thing in C++ at all without proper coding knowledge, meaning that everyone coding in C++, either spends too much time at it (I got to know to code in UScript initially like this lol
), or have already a strong coding knowledge from school or other sources.
The average modder won't be able to add something new to it by himself if needed (a new physics property needed to make the particle behave differently for example), even considering the source of that mod is released.
So, native coding for particles: yes, it would be the most "correct" way to do it, as it would get faster, using the right type and amount of resources and it doesn't need to run any spawn garbage code when using an actor for instance (and that's the small part of it, you didn't even consider the fact that an Actor has a huge load of variables that need to be stored in RAM, which are not used at all by the particles), however, it's a "no go" most of the times: you loose more than you win, if you want to use it for more things than just single player and all kinds of systems where UT is fully suported.
For instance, your SDK is great and I am sure is very fast and stable and gives a whole new set of possibilites to developers, however I am not seeing a single server hosting it as the servers are now (many of them run in Linux for instance, and you already stated you can't port it). At max, you will have people publishing maps using its features for single player, and some unique sp mods as well (from which I wanted the SDK one day for instance). Unless you provide cross-platform full support somehow, the SDK will be highly apreciated by other developers and SP players, while multiplayer only players won't use it at all (at least I don't see how).
Therefore, there are only UScript based solutions left, and in case of >@tack!< , UScript is the only thing he knows (sorry if I am wrong), in my case, is an option (I won't go to c++ unless it trully worths it, besides I lack most c++ knowledge relative UT anyway, but I know the its advantages and disadvantages somewhat), so actors are the only solution.
However, if people do it smartly enough, you can get a particle system well done and with a good performance using actors or UScript itself.
- Vertex meshes: you would be surprised on what you can actually do with these at UScript level, with some modelling and animation knowledge;
- Vertex meshes + normal translucent meshes: particles with trails;
- Vertex meshes + actor based particle sets: particles with some physics at a very low cost;
- Actor based particle sets: the very last resort when creating particles, but still viable.
Of course, you don't get anywhere the same flexibility as if you built them in C++, at all, however, considering the overall max graphical detail you can achieve in UT EVEN WITH C++, the trouble you get setting up the particles using properties in Ued or in a script, you get by building each particle set as a model or a models and actors (hybrid).
Also, if we go into the "very correct way of doing it", then I would say: native is actually not enough, you would have to do it in native, and only using the necessary hardware, and not stick with the CPU only (like using the GPU).
Sorry for the long post, this is indeed a very constructive discussion. Of course, I admit I may be wrong in anything I have said above, but that is my current idea of things, and I kinda have some "proof" of sort to speak to support what I said.
Either ways, if there's something either you or anyone else don't agree with me, speak up, I would like to learn something extra or clear out any misunderstanding I have over things.
When thinking in the developer, there are even more problems: you have to setup a proper development environment with the proper files (with UScript you don't have that trouble, it just takes Notepad++ with a plugin, UMake and you are ready to go), and if you do something wrong, strange things may happen.
C++ as a language is one of the most powerfull ones, but also one of the hardest to learn relative other languages. People used to ECMAScript based languages (JavaScript, UScript, ActionScript, WhateverScript), will have a hard time to understand how things work out. Only people working heavilly in ActionScript, JavaScript and PHP for instance, won't have such big difficulty though, since PHP is a crappy language to start with (a very strange and unique one), so people will be used to "differences", and PHP itself has some things very close to C++ syntax wise (the use of "->" to references instead of the usual "." in ECMAScript languages for instance), and with JavaScript and ActionScript you complement with object oriented programming and further coding knowledge, from here UScript is as easy as to breath (as a language) and C++ will have a much smaller level of difficulty.
But either ways, someone just used to UScript, won't be able to do a thing in C++ at all without proper coding knowledge, meaning that everyone coding in C++, either spends too much time at it (I got to know to code in UScript initially like this lol
), or have already a strong coding knowledge from school or other sources.The average modder won't be able to add something new to it by himself if needed (a new physics property needed to make the particle behave differently for example), even considering the source of that mod is released.
So, native coding for particles: yes, it would be the most "correct" way to do it, as it would get faster, using the right type and amount of resources and it doesn't need to run any spawn garbage code when using an actor for instance (and that's the small part of it, you didn't even consider the fact that an Actor has a huge load of variables that need to be stored in RAM, which are not used at all by the particles), however, it's a "no go" most of the times: you loose more than you win, if you want to use it for more things than just single player and all kinds of systems where UT is fully suported.
For instance, your SDK is great and I am sure is very fast and stable and gives a whole new set of possibilites to developers, however I am not seeing a single server hosting it as the servers are now (many of them run in Linux for instance, and you already stated you can't port it). At max, you will have people publishing maps using its features for single player, and some unique sp mods as well (from which I wanted the SDK one day for instance). Unless you provide cross-platform full support somehow, the SDK will be highly apreciated by other developers and SP players, while multiplayer only players won't use it at all (at least I don't see how).
Therefore, there are only UScript based solutions left, and in case of >@tack!< , UScript is the only thing he knows (sorry if I am wrong), in my case, is an option (I won't go to c++ unless it trully worths it, besides I lack most c++ knowledge relative UT anyway, but I know the its advantages and disadvantages somewhat), so actors are the only solution.
However, if people do it smartly enough, you can get a particle system well done and with a good performance using actors or UScript itself.
- Vertex meshes: you would be surprised on what you can actually do with these at UScript level, with some modelling and animation knowledge;
- Vertex meshes + normal translucent meshes: particles with trails;
- Vertex meshes + actor based particle sets: particles with some physics at a very low cost;
- Actor based particle sets: the very last resort when creating particles, but still viable.
Of course, you don't get anywhere the same flexibility as if you built them in C++, at all, however, considering the overall max graphical detail you can achieve in UT EVEN WITH C++, the trouble you get setting up the particles using properties in Ued or in a script, you get by building each particle set as a model or a models and actors (hybrid).
Also, if we go into the "very correct way of doing it", then I would say: native is actually not enough, you would have to do it in native, and only using the necessary hardware, and not stick with the CPU only (like using the GPU).
Sorry for the long post, this is indeed a very constructive discussion. Of course, I admit I may be wrong in anything I have said above, but that is my current idea of things, and I kinda have some "proof" of sort to speak to support what I said.
Either ways, if there's something either you or anyone else don't agree with me, speak up, I would like to learn something extra or clear out any misunderstanding I have over things.
-
Shadow
- Masterful
- Posts: 743
- Joined: Tue Jan 29, 2008 12:00 am
- Personal rank: Mad Carpenter
- Location: Germany
- Contact:
Re: particles
Well, there're no missunderstandings. Each approach to this problem has it's advantages and disadvantages. I myself do have the opinion that creating particle systems with actors is a waste of resources, the spawn checks, the destroy checks, that tons of variables etc.
Even regarding vertex particles, you DO need actors again.
Regarding the Linux issue I wanted to ask smirftsch on how to compile stuff for Linux correctly, so this is no problem, but at first I want the most stable and full featured build of the SDK on windows only, otherwise it'd be doubling my work probably.
Not done properly dosn't apply on guys who really know what they're doing. Critical stuff should be done in C++, UnrealScript is a gameplay coding language. People who only know UnrealScript won't have any problem with the SDK as all native functionality and actors simply require sub-classing and editing the base classes, I thought about that issue in the past already.
Also no one is forced to do things in C++, the C++ developer has to do his job the way others are able to use the features properly in UScript and the Editor.
The "only stick with cpu" issue doesn't apply here too, since all functions trace to the hardware they're intended for. Like the canvas or render functions, they run through the base render and get passed to the render device (opengl, glide, directx) which actually is maintained by the GPU.
But yes, even on UScript level dealing with actors there're a few optimizations possible, and I'd like to share them:
- use linked lists whenever possible, place one central (unique!) actor that holds several linked lists, for example for all emitters
- each emitter on the other hand holds a linked list of particles
- only update emitter / particles if necessary
- do occlusion checks and other performance checks (line check, fov check, radius check etc.)
- beware of possible replication issues
- use an actor recycling system (kinda tricky), you would pre-cache (prespawn) all particle-actors at startup and then just "place" them at the emitter origin and let them move on, when they're supposed to be destroyed move them back to the origin and so on... that way you hack around re-spawning tons of actors
This is what I advise anybody who wants to create particle systems in UScript with actors.
Well as I'm currently working on a real own Particle Engine, any tip, thought or optimization is welcome...
Even regarding vertex particles, you DO need actors again.
Regarding the Linux issue I wanted to ask smirftsch on how to compile stuff for Linux correctly, so this is no problem, but at first I want the most stable and full featured build of the SDK on windows only, otherwise it'd be doubling my work probably.
Not done properly dosn't apply on guys who really know what they're doing. Critical stuff should be done in C++, UnrealScript is a gameplay coding language. People who only know UnrealScript won't have any problem with the SDK as all native functionality and actors simply require sub-classing and editing the base classes, I thought about that issue in the past already.
Also no one is forced to do things in C++, the C++ developer has to do his job the way others are able to use the features properly in UScript and the Editor.
The "only stick with cpu" issue doesn't apply here too, since all functions trace to the hardware they're intended for. Like the canvas or render functions, they run through the base render and get passed to the render device (opengl, glide, directx) which actually is maintained by the GPU.
But yes, even on UScript level dealing with actors there're a few optimizations possible, and I'd like to share them:
- use linked lists whenever possible, place one central (unique!) actor that holds several linked lists, for example for all emitters
- each emitter on the other hand holds a linked list of particles
- only update emitter / particles if necessary
- do occlusion checks and other performance checks (line check, fov check, radius check etc.)
- beware of possible replication issues
- use an actor recycling system (kinda tricky), you would pre-cache (prespawn) all particle-actors at startup and then just "place" them at the emitter origin and let them move on, when they're supposed to be destroyed move them back to the origin and so on... that way you hack around re-spawning tons of actors
This is what I advise anybody who wants to create particle systems in UScript with actors.
Well as I'm currently working on a real own Particle Engine, any tip, thought or optimization is welcome...
Re: particles
wowowow i just come back from school and see this whole discussion lol, its nothing big that i make its just a simple effect like the weaponbases and bouncers on revs new dm map. and no i did not convert it to radians, my fault. and yes Uscript is the only thing i know a bit, by googling it ^^
Re: particles
i just checked and i see that ued already has rad as default? or is that what you meant? that i dont have to convert, well i didnt :p
BroadCastMessage(sin(150)$" "$sin(150*PI/180));
gives -0,714876429 0,5
heres the part of my script where it spawns:
BroadCastMessage(sin(150)$" "$sin(150*PI/180));
gives -0,714876429 0,5
heres the part of my script where it spawns:
Code: Select all
GetAxes(Rotation,X,Y,Z);
For(i=0;i<NumParticles;i++)
{
RandLoc = 2*PI*FRand();
If(AreaType == AT_Circle)
B = Spawn(class'Deeltje',self,,Location + Radius*FRand()*sin(RandLoc)*Y + Radius*FRand()*cos(RandLoc)*Z,Rotation);
etc.-
Feralidragon
- Godlike
- Posts: 5493
- Joined: Wed Feb 27, 2008 6:24 pm
- Personal rank: Work In Progress
- Location: Liandri
Re: particles
Well, you know how developers are: when a discussion gets interesting to both sides, it gets way big. The trade of opinions and ideas teach both sides a lot more than if we let the theme die.
As for your particles, I would personally do the calculations and spawn like this instead:
That way it will indeed create a circle, plus this way in case you rotate your actor, the particles will spawn considering that rotation, and you can create only part of the circle instead of the full thing, and look how simple it becomes without all the extra math and the amount of things you can already make to work together.
The concept is simple: do define a random set of points within a perfect circle, you set a random distance from the center where your particle will spawn at, and then you rotate the result distance vector/point from the center with a random angle, and voilá.
In case you're wondering about ((v >> r) >> Rotation):
Vector >> Rotation = Vector "rotated" by Rotation (well, just think that you have you have your meal: potatoes, rice and meat, they're in 3 different points, let's say that the meat is the point when rotation = 0, then you rotate your dish at the angle X the point will be somewhere else, well, this is basically what that operator does).
Let's say:
V2 = V1 >> Rotation;
is equivalent to:
GetAxes( Rotation, X, Y, Z);
V2 = V1.X*X + V1.Y*Y + V1.Z*Z;
@Shadow:
My point with the vertex particles, is that even so they need an actor indeed, they need only 1 for an amount equal to the amount of vertexes you have in the model.
Regarding your SDK and Linux, well, I'm glad to hear that then. Linux is a very good bet since many UT players have indeed Linux, and several servers use Linux to run UT dedicated servers. And yes, no need to double work (although you might have to change one thing or another anyway in the end, I think).
When I said "done properlly", I was thinking in people like BlackCheetah. He claimed once he could finally do stuff in C++ for UT, never saw a thing though, but I sure you if he did, he wouldn't do it right. My worries is that I know the community too damn well (much better than many people around here I believe), and if there's something that can torn a mod apart, are "average joes" blame your mod for anything that goes wrong (Antrax knows this better than anyone I know), and a C++ mod is more volatile, and if something out from normal happens, your stuff gets marked (even if you know what you're doing, bugs and crashes are always bound to happen: a missed error try catch, an infinite recursion, an infinite loop, all stuff which can bypass even the best coder. I work with some Linux developers everyday, and because of a little mistake like this, a certain program eventually ended up with a "kernel panic" when using it on wireless, not a good thing at all, I was actually the one who tested it and detected that issue, it worked fine by Ethernet though).
In C++ you have so much freedom and access to the system core resources, that when a mistake is made, it can lead to some ugly errors, most of them harmless though if you don't mess much around.
However, in the end, when something works perfectly fine, it worths the trouble by a million and motivates to do more stuff using it (I bet you get this feeling everytime you finish something and it surpasses your own initial expectations).
Also, yeah, no one is compelled to do a thing in C++, like I said previouslly, I could if I made a small effort, but by a simple option I don't and I don't feel obligated to, I just enjoy what other people way more advanced than me do in it instead (you, .:..:, etc). What I meant is that when someone does something in UScript, if it's enjoyable someone else will take that code and take it to another level. In C++, that's impossible: most people don't know how and simply can't know without some further proper coding knowledge, and the ones who can generally do their own stuff, and only support someone's else work for a very short period of time. This in UT of course (idk about other games and other communities).
About the CPU, in your case I am well aware of that (you stated that from the moment you presented us the SDK). I just know some things from other sources which state that only CPU and RAM when they should be using GPU and VRAM (Video Memory).
By now, if you may have realized I am talking about C++, UScript and such in a very general level, nothing very specific regarding projects or people, just the particles theme.
Regarding your UScript advices, I fully agree with all of them, but I just need to add something to 2 of them:
"- do occlusion checks and other performance checks (line check, fov check, radius check etc.)" - Do not use tick for this, use a timer or latent code for this. A tick running at least 60 times a second is too much if you can do the same thing 10 times a second or even less depending on the kind and priority of an update-
"- beware of possible replication issues" - Only a problem if the particles have to have a "cause-effect" function in the environment or other server actors. Otherwise just spawn them client-side only, and you will have 0 replication issues since you will be working like in a normal machine. I talk by some experience (I have a floor/wall debris system and some other visual features which only work client-side, and therefore I never had to worry about replication statements or the use of a simulated or normal function, just the RemoteRole and the way they are spawned are the only things having replication checks).
This has been indeed a good discussion
As for your particles, I would personally do the calculations and spawn like this instead:
Code: Select all
var() float MaxRadius; //Max Distance to spawn: circle radius
var() float AngleDeg; //Angle in degrees (360º for full circle, 180º for half, etc)
...etc...
function WhateverFunctionYouReCalling()
{
local rotator r;
local vector v;
...etc...
For(i = 0; i < NumParticles; i++)
{
r.Yaw = FRand()*AngleDeg*65536/360;
v.X = FRand()*MaxRadius;
If(AreaType == AT_Circle)
B = Spawn(class'Deeltje', Self,, Location + ((v >> r) >> Rotation), Rotation);
...etc...
The concept is simple: do define a random set of points within a perfect circle, you set a random distance from the center where your particle will spawn at, and then you rotate the result distance vector/point from the center with a random angle, and voilá.
In case you're wondering about ((v >> r) >> Rotation):
Vector >> Rotation = Vector "rotated" by Rotation (well, just think that you have you have your meal: potatoes, rice and meat, they're in 3 different points, let's say that the meat is the point when rotation = 0, then you rotate your dish at the angle X the point will be somewhere else, well, this is basically what that operator does).
Let's say:
V2 = V1 >> Rotation;
is equivalent to:
GetAxes( Rotation, X, Y, Z);
V2 = V1.X*X + V1.Y*Y + V1.Z*Z;
@Shadow:
My point with the vertex particles, is that even so they need an actor indeed, they need only 1 for an amount equal to the amount of vertexes you have in the model.
Regarding your SDK and Linux, well, I'm glad to hear that then. Linux is a very good bet since many UT players have indeed Linux, and several servers use Linux to run UT dedicated servers. And yes, no need to double work (although you might have to change one thing or another anyway in the end, I think).
When I said "done properlly", I was thinking in people like BlackCheetah. He claimed once he could finally do stuff in C++ for UT, never saw a thing though, but I sure you if he did, he wouldn't do it right. My worries is that I know the community too damn well (much better than many people around here I believe), and if there's something that can torn a mod apart, are "average joes" blame your mod for anything that goes wrong (Antrax knows this better than anyone I know), and a C++ mod is more volatile, and if something out from normal happens, your stuff gets marked (even if you know what you're doing, bugs and crashes are always bound to happen: a missed error try catch, an infinite recursion, an infinite loop, all stuff which can bypass even the best coder. I work with some Linux developers everyday, and because of a little mistake like this, a certain program eventually ended up with a "kernel panic" when using it on wireless, not a good thing at all, I was actually the one who tested it and detected that issue, it worked fine by Ethernet though).
In C++ you have so much freedom and access to the system core resources, that when a mistake is made, it can lead to some ugly errors, most of them harmless though if you don't mess much around.
However, in the end, when something works perfectly fine, it worths the trouble by a million and motivates to do more stuff using it (I bet you get this feeling everytime you finish something and it surpasses your own initial expectations).
Also, yeah, no one is compelled to do a thing in C++, like I said previouslly, I could if I made a small effort, but by a simple option I don't and I don't feel obligated to, I just enjoy what other people way more advanced than me do in it instead (you, .:..:, etc). What I meant is that when someone does something in UScript, if it's enjoyable someone else will take that code and take it to another level. In C++, that's impossible: most people don't know how and simply can't know without some further proper coding knowledge, and the ones who can generally do their own stuff, and only support someone's else work for a very short period of time. This in UT of course (idk about other games and other communities).
About the CPU, in your case I am well aware of that (you stated that from the moment you presented us the SDK). I just know some things from other sources which state that only CPU and RAM when they should be using GPU and VRAM (Video Memory).
By now, if you may have realized I am talking about C++, UScript and such in a very general level, nothing very specific regarding projects or people, just the particles theme.
Regarding your UScript advices, I fully agree with all of them, but I just need to add something to 2 of them:
"- do occlusion checks and other performance checks (line check, fov check, radius check etc.)" - Do not use tick for this, use a timer or latent code for this. A tick running at least 60 times a second is too much if you can do the same thing 10 times a second or even less depending on the kind and priority of an update-
"- beware of possible replication issues" - Only a problem if the particles have to have a "cause-effect" function in the environment or other server actors. Otherwise just spawn them client-side only, and you will have 0 replication issues since you will be working like in a normal machine. I talk by some experience (I have a floor/wall debris system and some other visual features which only work client-side, and therefore I never had to worry about replication statements or the use of a simulated or normal function, just the RemoteRole and the way they are spawned are the only things having replication checks).
This has been indeed a good discussion