2 more test screens, only for you

1) clipping decal shadow dots enables a bit lower system requirements than in case of pssm shadows, together with static lightmap (unfortunately there is an engine bug when mirror view applied for water, resulting in unupdated shadow positions):


2) using lod3 stencil shadows with static lightmap is also fine, maybe even better (unfortunately there is an engine bug resulting in too early clipping, at max lod0 distance):

Germanunkol: yeah the tutorial I follow is quite close to the Gimp one. I used too low resolution for the textures on the lot of the planets. The ice planet on the right isn't too good either. It's best to have the texture at least twice as big as the final planet result to get a good quality texture after spherize effect. Thanks for the link! Your planet looks beautiful on CSiS .

I still haven't found a nice way to create continents though, the tutorials you linked and I followed result in one solid texture, and the colour of the planet is a separate mix of layers which might give a faint hint that there are oceans and planets but if you look at a picture of earth, the tutorials never come close to the variety that a true earth planet has.



You see lush, deserts, oceans, cloud patches, shallow waters, mountain ridges, it's all well defined in reality.

@joozey, Im thinking you could get the effect of all that definition with some brushes made from rock and cloud textures. continents could start with a base color with a polygon selection tool, and then brush in the defined features, then a layer over the top for clouds brushed on, maybe even turn up the contrast on the alpha mask to make the edges more defined.

Joozey, I know exactly what you mean, I had the same problem back then.

One way that springs to mind is:
- Download a rock-image like this one: http://cgtextures.com/login.php?&tex...bg7ra0eg1m1flg6
- Duplicate the layer
- Blur and increase contrast on one of the layers and then use it as a "layer mask" for the other layer

That doesn't give you a perfect planet texture, but I think it's a pretty good start.
Result (I also played with the "curves" tool before setting the image as a layer mask):

Today i wrote a small DLL which receives the SDK and Scene instances from AckPhysX3 to do this:


and in motion:
https://www.youtube.com/watch?v=ATKePPp2TfE

The scene above uses 3k Particles. Anything more screws the FPS < 60. Though the problem here is that 3dgs particles need a function..or is there a way to create a particle without an always executing function7event and never dying?

Looks great! With A8 pro particle instancing is used so that you can show approx. 30k particles in your demo. Besides, try to pass NULL as function and step each frame with ptr_first and .link.next through all particles, updating lifespan to something >0, e.g. 100, and updating the .xyz position.

I am not 100% sure, but since wait(1) is not allowed in particle functions, I guess they are executed at once in one frame roughly as I described above. So, my tip can also likely be no improvement. I guess the main reason why your performance breaks down is just the casual overdraw.

@HeeIX: just have Comercial(and iam not going to pay 600€ more just for this )

And where should i pass NULL? in effect()?
And how do i acces the first created particle?(to get the linklist start)

Yes I know, that is why I am telling you this



I meant the particle event, like this:




Getting the first particle is a bit tricky, because you need a particle instance for ptr_first. I see two ways: 1.) create a dummy particle that is alive all the time and writes it's pointer into a global one, this can be used with ptr_first:



or 2.) you give the very first PhysX-particle an event that overwrite that pointer. If the particle is destroyed, you have to reset a flag or so to indicate, that you give the next PhysX-particle the function again.

Nevertheless, you have to indicate the PhysX-particle somehow, because it might be the case, that there are other particles as well, which don't belong to the fluid. I would set each's Physx-particle's skill1 or so to an identifier reserved for PhysX particles. In the loop, in which you update the particles, you check against this skill, and if and only if it matches the ID, you update it.

Ok i'll try to set the event to NULL.

But i think in this case instead of using the LinkList, i'll just put each registered particle into a Particle array, which allows faster iterating(no check for non Phys particle). This list is then directly given to my DLL to do the stuff. Might even kill 1 of 2 copy loops(resulting in a speedup)

working on an very easy shooter template that holds the
pure basic stuff. I got help from my friend Arrovs a few minor things need to work perfect and then it will be uploaded a.s.a.p. For me the reason to create this is that in the old days of A5 i liked the simple click and play thing as a Noob.
Soon A8 users will have this simple click and play to i hope


[video:youtube]http://youtu.be/TkyEPxHDoAQ[/video]