Cloud test

Community Forums/Showcase/Cloud test

MadJack(Posted 2008) [#1]
Just for giggles, have been amusing myself with a 3d cloud system (mouselook LMB = forward, RMB = back)

Particularly wanted to be able to create 'thunderheads' that the camera could fly up to and into. Have reasonably suceeded - but framerate isn't great even on my 8600GT. Blitz3d is really just not fast enough for this sort of stuff to be feasible.

[img

Press space to turn FPS on/off

I've included the source code. What would be really interesting is if someone were to convert the code to run under BlitzMax using MiniB3D and/or Blitz3d SDK- for a speed comparision. Yes - that would be really great! ;-)

The code uses the userlib Blitz3d+ (supplied), so if you want run the source, you'll need to copy the blitz3d+ dll and decls to your blitz3d userlib folder).

The camera can fly into the clouds but this part still needs some work as the clouds are effectively hollow. The programme also mucks about with the fog range if the camera's near a cloud blob - but it's not ideal.

http://madjack.fileburst.com/CLOUD_TEST.zip


Jerome Squalor(Posted 2008) [#2]
looks cool. to bad i only got 2 fps.


puki(Posted 2008) [#3]
I managed to increase the speed to 30 FPS.

EDIT:
I mean 42 FPS - it is currently default locked at 30FPS


MadJack(Posted 2008) [#4]
JS

Specs man, specs! What's your specs!

However, it's pushing around a lot of sprites so I'd imagine it does become a slideshow on some setups ;-)

Puki

Cool. Would really like to see the same code running under Blitzmax/miniB3d. That would be interesting.


puki(Posted 2008) [#5]
I'm not sure what BlitzMax can do here - It would probably run heaps faster using faster methods.

I reckon I can push it to 100 FPS.


puki(Posted 2008) [#6]
I think it is probably bent.

I squeezed it to 72 FPS.


MadJack(Posted 2008) [#7]
puki

'bent'? I know my programming methods are not particularly elegant, but 'bent'?! ;-)

But what are you doing to get that speed inc? I guess replacing the sprites with a single surface system would be an immediate option.


Yahfree(Posted 2008) [#8]
running the exe I get 33FPS on my 9600 GT... clouds look good up close, but far away they look toonish... (when the particles? turn into circles)


MadJack(Posted 2008) [#9]
Yahfree

but far away they look toonish

Yes - one of the probs with sprites is how they noticeably rotate when the camera is looking up/down along the y-axis. The solution is either to use a more and smaller sprites (to help obscure each sprite's rotation) or use a shape that won't show rotation - such as a circle.

So they do look 'toony' but if you built the rest of your game around that style, it would be ok.


GfK(Posted 2008) [#10]
The look a bit too circly for me.

That and they only run at 8-10fps (Intel GMA X3100)


MadJack(Posted 2008) [#11]
Gfk

A higher density of sprites would help solve that issue.

Wonder if Puki got any further?

I've just bought BlitzMax so I might make this my first BlitzMax project.


MGE(Posted 2008) [#12]
It will be slower in Blitzmax since there is no batching. Sorry...but true.


MadJack(Posted 2008) [#13]
Hmm. What if it was run through the Blitz3d SDK?


Gabriel(Posted 2008) [#14]
MGE is wrong. BlitzMax doesn't batch for you, but you can batch draw calls yourself quite easily.


MadJack(Posted 2008) [#15]
Because I'm profligate with my money, I've bought the B3d SDK as well. Will give this a go.


MadJack(Posted 2008) [#16]
Well that was a bit disappointing - I had hoped to just convert the Blitz3d code (to Blitzmax + B3dSDK) and get the exact same result as Blitz3d, only faster.

Instead there's all sorts of alpha/z-fighting issues and the puffy, PNG masked sprites are effectively 'borked'. And it doesn't seem to run much faster.

(MiniB3d gives better results but runs at slideshow speeds)




MGE(Posted 2008) [#17]
"MGE is wrong. BlitzMax doesn't batch for you, but you can batch draw calls yourself quite easily."

Yep....that's the holy grail saying around here, but no one has ever supplied code for both OpenGL and DirectX that does that. ;)


MadJack(Posted 2008) [#18]
Forget 'batch draw calls' - I just want the SDK to behave as Blitz3d does natively!


Dabhand(Posted 2008) [#19]
http://www.syntaxbomb.com/forums/attachment.php?attachmentid=389&d=1219067158

Compliments of the Red October.

Dabz

P.S. Its a cloud thing! :)


Gabriel(Posted 2008) [#20]
Yep....that's the holy grail saying around here, but no one has ever supplied code for both OpenGL and DirectX that does that. ;)


You don't need OpenGL or DirectX code to do it. I'm starting to think that you're not even talking about batching, but I don't really know what you are talking about, so I'm not sure what code you're looking for.


MGE(Posted 2008) [#21]
Batching as in something like this:

StartBatch()
AddQuad()
AddQuad()
AddQuad() ' etc,etc, until all sprites are cued.
EndBatch() ' Draw the batch

Usually this means using some kind of vertex buffer system ,etc, etc, in order to maximize the rendering process.

What was your interpretation of batching? Now I'm confoosed. :)


Gabriel(Posted 2008) [#22]
Batching just means doing all your drawing without unnecessary state changes. BlitzMax makes you change states manually with commands like SetColor, SetRotation and which image you draw with. So all you do is draw all your objects, sorted by texture and other states, and that's it. No changes to the underlying engine or whatever.

Vertex Buffers are something else, and no, I don't think BlitzMax does use them any more. As I recall, the DX7 driver was rewritten to use vertex buffers at one stage, and it made everything slower so it was dropped. Mind you, that may have been through a cautious implementation as I know there were bugs and/or extreme slowdown in Blitz3D related to vertex buffer implementation.


JoshK(Posted 2008) [#23]
Use fewer, larger particles with a lower alpha value.


MadJack(Posted 2008) [#24]
MGE/Gabriel

Stop hi-jacking my thread!

Leadwerks
Could do, but the thunderhead cloud models are a stress test. Looking for high detail clouds that can be viewed from any angle without noticeable sprite rotation (e.g. directly underneath but from some distance away, looking up - hence the fairly dense, circular sprites).

I wonder how the Leadwerks engine would handle this (as a straight port of the code)?


MadJack(Posted 2008) [#25]
Dabhand

Just seen your post regarding Red's clouds - will give them a go.


Gabriel(Posted 2008) [#26]
MGE/Gabriel Stop hi-jacking my thread!

Sorry, I thought we were discussing how you might make the effect faster.


MadJack(Posted 2008) [#27]
Gab

Sure thing - but I'm more concerned at how flaky the B3dSDK seems at first contact.

I wonder how the Xors engine would go...


MGE(Posted 2008) [#28]
Actually, we're not hijacking the thread at all. If you're going to use 2d sprites to simulate a 3d effect, you will probably need some kind of hardware support for batching.


MadJack(Posted 2008) [#29]
Ok - but I'm really just interested in how different engines handle a stress test like this in a fairly rough and ready way.


MGE(Posted 2008) [#30]
Actually, a simple sprite benchmark would be idea for this. I'm very curious if Sprite Candy/B3D would work better?


JoshK(Posted 2008) [#31]
The best way is to use a particle emitter for the cloud. Draw all the sprites in one vertex array, and make the vertex program face the quads towards the camera. You could also use a geometry shader to generate the quads, which would be even better, but I haven't gotten into geom shaders yet.

If you use a very faint alpha value for each particle, the rotation won't be very noticable. Crysis suffers from this same problem, but each particle is so faint the rotation is hardly noticable.


MadJack(Posted 2008) [#32]
MGE

I'll give that a shot next - single surface stuff!

Leadwerks
Yes - but I'm really aiming for that well defined edge, structure and bulk you can typically see on cumulus thunderheads.

I'm just tinkering, but at the back of my mind I'm turning over the idea of designing an aerial RPG that uses dramatic cloudscapes as its 'landscape'. In fact, there'd be no landscape at all - just sky.


MadJack(Posted 2008) [#33]
Even without geom shaders - how much better do you think the LW engine would handle this kind of stuff (than Blitz3d?).


JoshK(Posted 2008) [#34]
My first attempt used a bunch of particles to define the cloud shape like you are, and it was a total failure. I just posted some shots in the island thread showing the ones I have now. They aren't as large or as dense, but they look good.


Pongo(Posted 2008) [#35]
Single surface will give you a huge boost. On my current project I was getting frame issues at about 500 particles before single surface. Now with a single surface system I can move 10,000 particles with no issues at a smooth frame rate. There is nothing special about my system, and it's based off of code that is in the code archives.

On the cloud side of things, this is not single surface(uses sprites), but may be useful to some. If you feel this is hijacking your thread I will remove the link. I understand you may be trying to do something quite different with your system.
Get it here.

Anyways,... my method involves simply using several sprites per cloud to build a bit of a mass that can move around and have some nice depth to it. It beats a system of just a single sprite per cloud, but you will see popping when things rotate.


Even with a single surface sytem, I'm not sure you will ever get the performance you need out of Blitz though. Things will always slow down when there is a lot of alpha blending, and what you are doing requires a lot of alpha blending.


JoshK(Posted 2008) [#36]
Blitz's speed at alpha blending is limited by the GPU, and it won't make any difference whether you are using Blitz, your own OpenGL rendering, or Crysis, it will still be the same speed.


MGE(Posted 2008) [#37]
Pongo - Could you supply an exe version for us non bb (Bmax) users?

Also, would love to see your 10k particle system running. Any chance of an exe of that too?

Thanks. ;)


HNPhan(Posted 2008) [#38]
http://www.vterrain.org/Atmosphere/Clouds/


Pongo(Posted 2008) [#39]
MGE

Here is a link with .exe files for the clouds

This is the same as the code only version above, so no need to download if you have B3d.

I will put together an exe of the particles also, but I'll start a new thread in the showcase instead of hijacking this thread. I have to put a few things together for that, so it will not be until later today or tomorrow before that is posted.


Jerome Squalor(Posted 2008) [#40]
very nice although i have to admit, i liked the cartoony style one at the top of this post.


MadJack(Posted 2008) [#41]
I will get back to this shortly - dealing with some Steam issues at the moment.

The only comment I'd make at the mo' is that these wispy sprite clouds are ok, but I'm looking for big, thunderhead type clouds - which is why I put together the first demo (even if it does appear cartoony).


Pongo(Posted 2008) [#42]
yes, those are definitely a different style of clouds.

I like the density and darker clouds near the base of yours, but the need for so many individual sprites is what is killing the frame rate. I'm sure there is a nice solution somewhere in the middle of these techniques though, and a single surface system is probably the first place to start.


MadJack(Posted 2008) [#43]
Pongo

As Josh pointed out, there's a vid card hardware limit for alpha blending beyond how fast the code or rendering engine runs.

I expect the alpha blending load could be reduced by using sprites with alpha = 1. But then there's noticeable 'popping' as the z_order between overlapping sprites changes even a little bit.

Perhaps a solution for that is to use single billboard sprites for very distant clouds (one sprite = one whole cloud). For medium distant clouds (that may be viewed at a considerable angle above/below) ,construct the cloud out of mesh spheres with edge vertices alpha'd to transparent and kept pointed at the camera.

For foreground clouds, go with .5 alpha single surface quads.


MGE(Posted 2008) [#44]
You could even use single larger sprites (for closer views) that are pre-rendered to look like multiple cloud clusters. This is done alot with explosion particle systems.


MadJack(Posted 2008) [#45]
You could even use single larger sprites (for closer views)

Yes but again, with larger sprites, you run into obvious sprite rotation issues when you're beneath or above the cloud looking up/down - which destroys the illusion. It's all good if you don't allow too much camera pitch.


Pongo(Posted 2008) [#46]
those rotations are always going to be a problem with larger sprites. A couple of solutions are to make your own look-at function that only orients the cloud sprite on the y axis, but does not allow it to rotate on the X and Z. This works pretty well until you go right over the top of a cloud. The other thing that can work well, and I think you are already doing this, is to fade out the cloud as you approach it and use camera fog for inside the cloud.

Remember you can adjust the near range to be a negative number also. This lets you keep a consistent far depth while putting you inside the fog.


MadJack(Posted 2008) [#47]
Pongo/MGE

Perhaps another way is to move away from sprites/meshes altogether and calc a single texture each frame, based on fractals and mapped to a surrounding sphere.

Check out this link;

http://www.simul.co.uk/CloudWright


HNPhan(Posted 2008) [#48]
or this:
http://www.bleank.com/Resource/Gallery/Video/wipperfume/MakingOf.avi
best ive seen so far


Pongo(Posted 2008) [#49]
TigerZ - that is awesome.