Ah so simple, yet so not so simple.
I have a lovely fluid solution after many hours, and it renders all onto a flat 2D plane. Now I hadn't really thought much about how the rest of the 3D scene will sit with this fluid. I can't just have it all float over the top of it nor hide underneath it, I need it to merge with the fluid, and as It's a 2D plane by default objects just stick thru it with hard edges ruining the illusion of the 3D for example:
It is quite jarring where the cube suddenly enters the fluid. So I need to mask the fluid away based on the proximity of the cubes or the depth they sit at... simple.. I thought. Nope requires editing shaders which is never simple. But alas I finally prevailed and figured it out, the effect is almost unnoticeable, which is good because it is meant to be something you do not notice, versus clearly noticing how bad the above images is. Also the particles will fade out gently around the cubes not just suddenly get clipped by them.
So it looks better like this
Done with help from this site here:
Or even betterer like this:
Wonderful, job done ( aside from figuring out how to vertex color particles within the shader now )
Except none of it runs on the actual iOS device DOES IT!!!!!!
So back to the drawing board, and to find a way to capture camera depth that works in iOS and PRAYING all the shader jiggery I am doing will continue to work.
And how nice do a few cubes look ( only after 200 hours in Unity too! )
Phew redid pretty much everything from scratch and got it working on iPad
And Just had the idea to have the fluid depth take into account the brightness of the fluid, so brighter fluid is closer to the camera, to help break up the linear fog, works quite well
Now to just got get particle depth working again, and tidy things up ( remove all the fudge and hack )
Just added Velocity Texture support
Can now do kickass never seen beforeness such as but not limited to: suck in fluid like a crazy blackhole upon hitting a cube, spurt out red jets of fury if you miss a box... and other such nonsense
As it just instances / splats a texture directly into the velocity field such as:
The colours represent the angle to direct the fluid. Hurt my brain working out how to draw such an image in Photoshop but tadda
The above is basically pushing fluid out in allow directions uniformly
FINALLY got the fluid simulation working with none square area... took 17 hours of docking about poking in the dark and fumbling about banging my head
FluidAspectWorking
The way I see it you have normal programming like JavaScript lets say that's difficulty 1, then twice as hard as that is doing it really well with proper abstraction and organisation with good performant code being twice as difficult at level 2, then you have writing graphics shaders at level 3, implementing a fluid sim with a shader level 4, writing the formulas used for the fluid sim level 5, and understanding that fucking picture at level 10
But I do keep surprising myself, after sticking with a few 'impossible' tasks for a while, they become... understandable. Most of what makes things look so scary or beyond your capacity is not understanding the language something is written in. When new things use a different vocabulary it creates the impression that it is forever beyond comprehension. Time and time again I have felt this way despite knowing full well I can learn new languages and then suddenly the impossible becomes simple.
I am probably the only human being that has both the persistence and ability to get down and nerdy with a simulation like this, and still possess enough artistic ability and eye for detail to make it look good too... hell I might even be sensible enough to make something people would enjoy playing on top of that... but lets not get too carried away
Most normal people are scared off by how complicated adding feature to a fluid sim are, I am clearly immune to the normal healthy desire to run away screaming
even though this was a side embellishment to a boring whack a mole game, I'm thinking I need to make something that uses this fluid sim as the key gameplay mechanic
hubris aside though... I spent 17 hours just trying to fix the aspect ratio / render in a none square area
Oh and then I checked the performance increase of rendering less pixels / cells in the fluid sim with this fantastic optimisation:
Yup, around 1ms at best..... FFS
On the iPhone the increase is probably a bit higher, but even still.... premature optimisation strikes again
Testing with higher resolution simulation and the result is:
Ooh 2 more frames per second
Well at least it is making a difference... glass half full.. and it is saving some memory... *sigh*
I have a lovely fluid solution after many hours, and it renders all onto a flat 2D plane. Now I hadn't really thought much about how the rest of the 3D scene will sit with this fluid. I can't just have it all float over the top of it nor hide underneath it, I need it to merge with the fluid, and as It's a 2D plane by default objects just stick thru it with hard edges ruining the illusion of the 3D for example:
It is quite jarring where the cube suddenly enters the fluid. So I need to mask the fluid away based on the proximity of the cubes or the depth they sit at... simple.. I thought. Nope requires editing shaders which is never simple. But alas I finally prevailed and figured it out, the effect is almost unnoticeable, which is good because it is meant to be something you do not notice, versus clearly noticing how bad the above images is. Also the particles will fade out gently around the cubes not just suddenly get clipped by them.
So it looks better like this
Done with help from this site here:
Link: chrismflynn.wordpress.com --- fun-with-shaders-and-the-depth-buffer
Or even betterer like this:
Wonderful, job done ( aside from figuring out how to vertex color particles within the shader now )
Except none of it runs on the actual iOS device DOES IT!!!!!!
So back to the drawing board, and to find a way to capture camera depth that works in iOS and PRAYING all the shader jiggery I am doing will continue to work.
And how nice do a few cubes look ( only after 200 hours in Unity too! )
Phew redid pretty much everything from scratch and got it working on iPad
:-P
And Just had the idea to have the fluid depth take into account the brightness of the fluid, so brighter fluid is closer to the camera, to help break up the linear fog, works quite well
Now to just got get particle depth working again, and tidy things up ( remove all the fudge and hack )
Just added Velocity Texture support
Can now do kickass never seen beforeness such as but not limited to: suck in fluid like a crazy blackhole upon hitting a cube, spurt out red jets of fury if you miss a box... and other such nonsense
As it just instances / splats a texture directly into the velocity field such as:
The colours represent the angle to direct the fluid. Hurt my brain working out how to draw such an image in Photoshop but tadda
The above is basically pushing fluid out in allow directions uniformly
FINALLY got the fluid simulation working with none square area... took 17 hours of docking about poking in the dark and fumbling about banging my head
>_<
FluidAspectWorking
The way I see it you have normal programming like JavaScript lets say that's difficulty 1, then twice as hard as that is doing it really well with proper abstraction and organisation with good performant code being twice as difficult at level 2, then you have writing graphics shaders at level 3, implementing a fluid sim with a shader level 4, writing the formulas used for the fluid sim level 5, and understanding that fucking picture at level 10
But I do keep surprising myself, after sticking with a few 'impossible' tasks for a while, they become... understandable. Most of what makes things look so scary or beyond your capacity is not understanding the language something is written in. When new things use a different vocabulary it creates the impression that it is forever beyond comprehension. Time and time again I have felt this way despite knowing full well I can learn new languages and then suddenly the impossible becomes simple.
I am probably the only human being that has both the persistence and ability to get down and nerdy with a simulation like this, and still possess enough artistic ability and eye for detail to make it look good too... hell I might even be sensible enough to make something people would enjoy playing on top of that... but lets not get too carried away
Most normal people are scared off by how complicated adding feature to a fluid sim are, I am clearly immune to the normal healthy desire to run away screaming
even though this was a side embellishment to a boring whack a mole game, I'm thinking I need to make something that uses this fluid sim as the key gameplay mechanic
hubris aside though... I spent 17 hours just trying to fix the aspect ratio / render in a none square area
:-/
Oh and then I checked the performance increase of rendering less pixels / cells in the fluid sim with this fantastic optimisation:
Yup, around 1ms at best..... FFS
On the iPhone the increase is probably a bit higher, but even still.... premature optimisation strikes again
Testing with higher resolution simulation and the result is:
Ooh 2 more frames per second
:-/
Well at least it is making a difference... glass half full.. and it is saving some memory... *sigh*
Finally gave in after being driven up the wall by MonoDevelop for the last time... Moved to Microsoft VisualStudio on Windows, ah now everything just works-ish
Took forever to get communication working between VisualStudio on Windows and Unity on the Mac, so that you can double click debug logs entries and files in Unity and have it jump to the right Project / File and Line Number in Visual Studio running in a Virtual machine on the Mac. Had to write my own PC EXE acting as a bridge and all kinds of funky stuff... But I just couldn't stand MonoDevelop or Xamarin anymore, they are such junk.
Between that, and upgrading to the new Unity... then upgrading to another new Unity, then upgrading the heart of the FluidSim code from JavaScript to C# version, and moving to iOS 7, and a new iPad.... eaten all my time! No game work done!
And I'm really fretting and struggling around the concept / design / look and feel. I need to nail it down now, but it is impossible to draw or even photoshop mockup any of the themes I have in my head.
Maybe better approach is to have a few visual ideas / concepts and start playing around in Unity bringing them to life, then in a serendipitous manner discover and stumble upon something I like that I may never have thought of otherwise. Just get the wheels moving instead of being stuck in planning limbo.
Toying around with various visual concepts in this mockup, I have since abandoned this concept:
Playing around with the idea of using DOF / Spherical Aberrations or 'Bokeh' effects
Playing around with the idea of using DOF / Spherical Aberrations or 'Bokeh' effects
Coming Soon...
Well better late than never, I have been working on my first game, first real project in Unity and this is the first time I have bothered to write about any of it!
What it looks like right now, countless hours bring you a very exciting logo and some cubes and particles
That and eveeeeerything behind the scenes you cannot see or arguably even care about... took... forever! seriously.. for---ever - your mind could not even accept how long even if it could comprehend it.
If you wish to make an apple pie from scratch, you must first invent the universe -- Carl Sagan
I don't even want to contemplate what the work would be like without Unity making a good start on that Apple Pie for me
If I have seen further it is only by standing on the shoulders of giants -- Isaac Newton
I am writing a few articles for things in the past on some of the hurdles so save me explaining the ordeal here, go read those and you should get the picture
---
Totally easy to follow nesting of loops.. *hangs head*
What it looks like right now, countless hours bring you a very exciting logo and some cubes and particles
:-P
:That and eveeeeerything behind the scenes you cannot see or arguably even care about... took... forever! seriously.. for---ever - your mind could not even accept how long even if it could comprehend it.
If you wish to make an apple pie from scratch, you must first invent the universe -- Carl Sagan
I don't even want to contemplate what the work would be like without Unity making a good start on that Apple Pie for me
If I have seen further it is only by standing on the shoulders of giants -- Isaac Newton
I am writing a few articles for things in the past on some of the hurdles so save me explaining the ordeal here, go read those and you should get the picture
---
Totally easy to follow nesting of loops.. *hangs head*
Post Effects in Unity are fun! / Screenspace effects / Image effects / Post Processing etc
Though they often run very very slow on iOS devices if at all, but if some care is taken by reducing the resolution, you can still do some nice things
I edited the built in effects for vignette to well correctly do vignette for a start as vignette does not just mean make the edges blacker, you are simulating a drop in exposure essentially and unless you use HDR this means it will look like mud in a game just uniform ally blackening the edges despite how bright or none bright the contents is. And here Contrast adjustments are your friend so by darkening and increasing the contrast as it gets cooer to the edge you better approximate the 'look' that vignetting has, bright objects stay bright and dark objects get even darker. *feels quite smug for probably being the only person on Earth to have bothered to notice this was wrong and fix it* subtle stuff but it makes it looks nicer, and more photographic:
I also removed the aberration effect from the shader when set to 0 as this kills the performance on iOS. And reducing the resolution for the blur so it runs faster on mobile. End result I am still pulling 50 fps on iPad 4 with vignette with edge blur color correction 4x anti aliasing but only if It's at max 1024x768 ( none retina ) forget doing post effects at retina res just yet
:-)
Oh and theres some more fun trying to find where Unity forces the resolution in Xcode source files
:-)
Clue it is in 'AppleController.mm' under 'QueryTargetResolution' if you want exact control, just note changing the resolution mid game only works going down res, up res crashes ( known bug in Unity )
And note you can now change framerate from the default lowly 30 with:
Application.targetFrameRate = 60;
Though you will drain more battery
More post effect fun times:
Editor Graphical Bugs:
Fluid Simulation, ah where to even begin
I'm busy working on a game and wanted to add some nice subtle touches. To have particles in the air or embers emitted from destroyed 'items' and have them not just dart about the screen as is per usual with particles. But to interact with each other, with objects in the scene that are moving in and with the users touch input on the screen, thus bringing them to life a bit. Air is basically a fluid so essentially it is a fluid dynamics problem. One I had the naivety to think I could solve simply
How hard can it be to just have particles move about and push each other around.
Surely someone has already done this and I can just use that.
Now first off there are various kinds of approach to fluids sims, all with trade offs. Some good at 2D bad at 3D, some good at gases and turbulent spirals but bad at contiguous bodies of water e.g. with surface tension. The approach for modeling say a bucket filling up with water versus a room full of hot smoke are very different.
For Unity I have found a couple of libraries
FluidSim by Philip Heckinger ( Pheck )
What appears to be a good, well implemented version, best I have found for Unity for 2D fluids
A 2D CPU or GPU accelerated implementation using 'Eulerian' method of dividing a space into cells with velocity/pressure vectors
I inquired with the creator and he had added 'vorticity confinement' but for his uses decided to remove it for performance it added little
And has not added 'viscous diffusion'
--
Very similar to the implementation here by 'Scrawk' done in Unity3D
However this implementation is incomplete and I am too stupid to work out how to augment it ;-D
it is incomplete as it is itself based upon an implementation by Philip Rideout who'm decided to leave out Viscous Diffusion and Vorticity Confinement as he did not require them ( though fluidsim above also omits these things )
The Little Grasshopper - Simple Fluid Simulation ( written in C )
Which is itself based upon the work here in GPU Gems 1 by Mark J. Harris:
And some have found inspiration from the work of Jonathon M. Cohen of NVIDIA Research here:
And in this research here by Jos Stam for Alias
Real-Time Fluid Dynamics for Games
A couple of people I found used Jos Stams work
This here which seems broken by VIC20
And work by NoiseCrime ( whom wants to keep the efforts to himself "part of a bigger project and as such i'm unable to release the code at present" )
Another article by Mick West
Practical Fluid Mechanics
And then theres the very impressive work of Grant Kot:
Who has produced a realtime sim combined various methods and the only one I have seen that tackles surface tensions and manages to merge a good gas/swirly swim with solid water like properties too. Check GFlow HD for iPad ( free ) though I didn't fancy attempting to port this to C# and all the performance implication that might have.
And then there is Fluvio for Unity3D by Thinksquirrel Software
Which is a 3D particle based approach using what he claims is SPH ( Smoothed Particle Hydrodynamics ) but I have failed to see any evidence of a fluid sim at work here. It just looks awful. I'm possibly wrong and it is amazing but the demos and videos show it doing a poor job at pretty much everything. Understandably doing 3D fluids in Unity is going to be tricky and theres nothing else on the store that does what Fluvio does... but I'm left unimpressed by the demos and how coarse they are, they barely exhibit any of the behavior I would define a fluid by. More like a series of balls attached together with weak springs... and It's not exactly 'cheap' either. Maybe I am missing something! as the free demo only lets you use 100 particles kinda making it impossible to test It's metal.
And quite annoyingly the guys at Unity seem to have solved exactly what I need with a SPH Fluid solution for Shuriken particles here:
Look for video here 'Fluid Solver'
( what an awful website Unity! )
---
Ok I purchased the Unity Fluidsim and have started trying to make sense of it and bend it to my will!:
Got it running fairly well on the phone thankfully, I only need it low res ( unlike the high res in the video ) and it is working fine with all the post effects and a ton of particles, which is surprising for a phone! ( iPhone 5 )
Main problem now is getting it to interact with touch input, how to get it to push the fluid around. It has build in collision detection of sorts but it is totally rubbish so I will likely have to do it all myself... that is once I figure out how this is all setup internally *starts prodding and poking the code looking very confused
With no description and no code and no sign of any further work on it, just a video showing how cool it is ;-P *raises fist to the sky*
This is way more involving than I had hoped for, I just wanted to be able to touch the fluid and swish it about... simple I thought. I just spent most of the day writing multi touch code to detect angle and velocity to even get started on the problem. The way this 'Fluidsim' works is a bit nuts in terms of updating various properties per frame, it just polls at regular intervals even if nothing has changed, fair enough, but I want it to be a bit more performant than that and update only when something has changed and only draw the thing that has changed not loop thru all objects process each one. Nightmare.
Next problem how to make a tap push fluid around it in every direction. Seems so simple but yet again, nope hard as a pixel/point can only have one direction at a time naturally. So to have it move in all you need a circular shape with each pixels direction set to say from the center of the circle, not too complicated that is if you are used to writing shader code. Dealing with colors and directions as numbers/vectors hurts my brain immeasurably. Well figured that out and it was ridiculously simple in the end once my brain wrapped around it and of course first solved it in an over clever complicated and highly convoluted manner.
Here is a video of multi touch input running on my desktop computer:
And now after many days banging my head against the proverbial wall, here are particles suspended in fluid *drum roll*
now just to make it look nice, like dust glinting in sunbeams, and yes it is lagging and a bit jittery but I'm working on that
Never in my life have I struggled so much, long days with nothing to show for them, mindless trying different combination of things. But I prevail victorious, my stoicism knows no bounds.
Turns out the difficulty I was having was two fold, one a bug in Unity itself which was fixed 2 days before I started working on this!!!! but I had neglected to update. And secondly a continuing bug that prevents ReadPixels to work when Anti Aliasing is enabled on iOS. Then it was only am after of mere... 10's of hours to get it working properly ;-P
Now I need to work on the performance, using object pools and trying to augment the existing particle system instead of lots of floating quads each with expensive transforms and a heavy 3D physics engine attached to each particle.
I'm curious as to if an image based approach also running on the GPU would have been easier and likely more performant... tempting.. even if it does largely negate the work I have done
Projects like TC Particles using DirectX 11 looks amazing :
Though $100 and more importantly limited to Windows machines not good, $350 for the source code
It says it has a fallback to Unity built in Shuriken particles with no DX11, though who knows what benefits and drawbacks this brings.
Watch this video and be amazed ( presuming you are in the year range 2013-2016 otherwise you will be moderately amused at how basic it is )
--
Just got it working with Unity built in Particle System ( Shuriken ) which has sped it up immensely as expected so now handles many thousands more particles with ease. And used the Unity Profiler to track down and remove a bunch of GC crippling code that was stuffing the garbage collecting with megabytes a second of 'new' operations, so easy to slip up and do that
Ah balls... I just very cleverly made some 'optimized' code then realized due to a limitation out of my hands ( Shuriken ) it intact makes it slower, then I make some more very clever code for combining touch movements and running them at a custom regular interval instead of instantly / irregularly and often too often.... and then I realize the premise of the whole optimization was based on an incorrect assumption and have in fact worked really hard at undoing someone else's very clever optimisations because I assumed it was being stupid. FAIL
In any case despite most of my efforts being counter productive, the fluid sim is running even faster now
And after finding several ways of making it slower, I now know ( hopefully ) how to make it even fasterer! except now I'm shattered and being attacked by wasps ( they enter the window after a certain time en masse to harass and make me goto bed )
I'm busy working on a game and wanted to add some nice subtle touches. To have particles in the air or embers emitted from destroyed 'items' and have them not just dart about the screen as is per usual with particles. But to interact with each other, with objects in the scene that are moving in and with the users touch input on the screen, thus bringing them to life a bit. Air is basically a fluid so essentially it is a fluid dynamics problem. One I had the naivety to think I could solve simply
:-)
How hard can it be to just have particles move about and push each other around.
Surely someone has already done this and I can just use that.
Now first off there are various kinds of approach to fluids sims, all with trade offs. Some good at 2D bad at 3D, some good at gases and turbulent spirals but bad at contiguous bodies of water e.g. with surface tension. The approach for modeling say a bucket filling up with water versus a room full of hot smoke are very different.
For Unity I have found a couple of libraries
FluidSim by Philip Heckinger ( Pheck )
What appears to be a good, well implemented version, best I have found for Unity for 2D fluids
A 2D CPU or GPU accelerated implementation using 'Eulerian' method of dividing a space into cells with velocity/pressure vectors
I inquired with the creator and he had added 'vorticity confinement' but for his uses decided to remove it for performance it added little
And has not added 'viscous diffusion'
--
Very similar to the implementation here by 'Scrawk' done in Unity3D
However this implementation is incomplete and I am too stupid to work out how to augment it ;-D
it is incomplete as it is itself based upon an implementation by Philip Rideout who'm decided to leave out Viscous Diffusion and Vorticity Confinement as he did not require them ( though fluidsim above also omits these things )
The Little Grasshopper - Simple Fluid Simulation ( written in C )
Which is itself based upon the work here in GPU Gems 1 by Mark J. Harris:
And some have found inspiration from the work of Jonathon M. Cohen of NVIDIA Research here:
And in this research here by Jos Stam for Alias
Real-Time Fluid Dynamics for Games
A couple of people I found used Jos Stams work
This here which seems broken by VIC20
And work by NoiseCrime ( whom wants to keep the efforts to himself "part of a bigger project and as such i'm unable to release the code at present" )
Another article by Mick West
Practical Fluid Mechanics
And then theres the very impressive work of Grant Kot:
Who has produced a realtime sim combined various methods and the only one I have seen that tackles surface tensions and manages to merge a good gas/swirly swim with solid water like properties too. Check GFlow HD for iPad ( free ) though I didn't fancy attempting to port this to C# and all the performance implication that might have.
And then there is Fluvio for Unity3D by Thinksquirrel Software
Which is a 3D particle based approach using what he claims is SPH ( Smoothed Particle Hydrodynamics ) but I have failed to see any evidence of a fluid sim at work here. It just looks awful. I'm possibly wrong and it is amazing but the demos and videos show it doing a poor job at pretty much everything. Understandably doing 3D fluids in Unity is going to be tricky and theres nothing else on the store that does what Fluvio does... but I'm left unimpressed by the demos and how coarse they are, they barely exhibit any of the behavior I would define a fluid by. More like a series of balls attached together with weak springs... and It's not exactly 'cheap' either. Maybe I am missing something! as the free demo only lets you use 100 particles kinda making it impossible to test It's metal.
And quite annoyingly the guys at Unity seem to have solved exactly what I need with a SPH Fluid solution for Shuriken particles here:
Look for video here 'Fluid Solver'
( what an awful website Unity! )
---
Ok I purchased the Unity Fluidsim and have started trying to make sense of it and bend it to my will!:
Got it running fairly well on the phone thankfully, I only need it low res ( unlike the high res in the video ) and it is working fine with all the post effects and a ton of particles, which is surprising for a phone! ( iPhone 5 )
Main problem now is getting it to interact with touch input, how to get it to push the fluid around. It has build in collision detection of sorts but it is totally rubbish so I will likely have to do it all myself... that is once I figure out how this is all setup internally *starts prodding and poking the code looking very confused
With no description and no code and no sign of any further work on it, just a video showing how cool it is ;-P *raises fist to the sky*
This is way more involving than I had hoped for, I just wanted to be able to touch the fluid and swish it about... simple I thought. I just spent most of the day writing multi touch code to detect angle and velocity to even get started on the problem. The way this 'Fluidsim' works is a bit nuts in terms of updating various properties per frame, it just polls at regular intervals even if nothing has changed, fair enough, but I want it to be a bit more performant than that and update only when something has changed and only draw the thing that has changed not loop thru all objects process each one. Nightmare.
Next problem how to make a tap push fluid around it in every direction. Seems so simple but yet again, nope hard as a pixel/point can only have one direction at a time naturally. So to have it move in all you need a circular shape with each pixels direction set to say from the center of the circle, not too complicated that is if you are used to writing shader code. Dealing with colors and directions as numbers/vectors hurts my brain immeasurably. Well figured that out and it was ridiculously simple in the end once my brain wrapped around it and of course first solved it in an over clever complicated and highly convoluted manner.
Here is a video of multi touch input running on my desktop computer:
And now after many days banging my head against the proverbial wall, here are particles suspended in fluid *drum roll*
now just to make it look nice, like dust glinting in sunbeams, and yes it is lagging and a bit jittery but I'm working on that
Never in my life have I struggled so much, long days with nothing to show for them, mindless trying different combination of things. But I prevail victorious, my stoicism knows no bounds.
Turns out the difficulty I was having was two fold, one a bug in Unity itself which was fixed 2 days before I started working on this!!!! but I had neglected to update. And secondly a continuing bug that prevents ReadPixels to work when Anti Aliasing is enabled on iOS. Then it was only am after of mere... 10's of hours to get it working properly ;-P
Now I need to work on the performance, using object pools and trying to augment the existing particle system instead of lots of floating quads each with expensive transforms and a heavy 3D physics engine attached to each particle.
I'm curious as to if an image based approach also running on the GPU would have been easier and likely more performant... tempting.. even if it does largely negate the work I have done
Projects like TC Particles using DirectX 11 looks amazing :
Though $100 and more importantly limited to Windows machines not good, $350 for the source code
It says it has a fallback to Unity built in Shuriken particles with no DX11, though who knows what benefits and drawbacks this brings.
Watch this video and be amazed ( presuming you are in the year range 2013-2016 otherwise you will be moderately amused at how basic it is )
--
Just got it working with Unity built in Particle System ( Shuriken ) which has sped it up immensely as expected so now handles many thousands more particles with ease. And used the Unity Profiler to track down and remove a bunch of GC crippling code that was stuffing the garbage collecting with megabytes a second of 'new' operations, so easy to slip up and do that
:-)
I love you built in Profiler!Ah balls... I just very cleverly made some 'optimized' code then realized due to a limitation out of my hands ( Shuriken ) it intact makes it slower, then I make some more very clever code for combining touch movements and running them at a custom regular interval instead of instantly / irregularly and often too often.... and then I realize the premise of the whole optimization was based on an incorrect assumption and have in fact worked really hard at undoing someone else's very clever optimisations because I assumed it was being stupid. FAIL
In any case despite most of my efforts being counter productive, the fluid sim is running even faster now
:-P
And after finding several ways of making it slower, I now know ( hopefully ) how to make it even fasterer! except now I'm shattered and being attacked by wasps ( they enter the window after a certain time en masse to harass and make me goto bed )
Every little thing in making a game is a hurdle, or at least a dozen google searches then a hurdle
Today wrote my own InputManager for multi touch, made it way smarter than I should have, it will look for a special component on the object you touch ( which it find by doing ray cast from the camera ) if none was found it can look at the object parent, and parents parent etc till it finds one, it can also contact ALL parents if they have a listener on them, simple really. I can also have it auto add a component to the touched object that caches all this so it is fast without having to perform lookups every time.. like a boss
So code to have good component orientated design to handle touching the iPad screen:
But that's a bit misleading as that contains code to auto add components and handle duplicate objects, singletons and such
But you get the idea, every little tiny thing, involves 100 other tiny things and so on
Lets not even think about how the ray cast to find the touched object itself is leaning on 1000's of lines of physic engine code and scene caches to aid in speed
Speaking of ridiculous code, I have been slowly write examples for various c# concepts and functionality...
All of this, and none of it actually visibly does a damn thing. In fact at his point all I have done in Unity is make a box move, but I decided to learn the language first so learn it I shall *grumble*
Today wrote my own InputManager for multi touch, made it way smarter than I should have, it will look for a special component on the object you touch ( which it find by doing ray cast from the camera ) if none was found it can look at the object parent, and parents parent etc till it finds one, it can also contact ALL parents if they have a listener on them, simple really. I can also have it auto add a component to the touched object that caches all this so it is fast without having to perform lookups every time.. like a boss
So code to have good component orientated design to handle touching the iPad screen:
But that's a bit misleading as that contains code to auto add components and handle duplicate objects, singletons and such
:-)
But you get the idea, every little tiny thing, involves 100 other tiny things and so on
Lets not even think about how the ray cast to find the touched object itself is leaning on 1000's of lines of physic engine code and scene caches to aid in speed
Speaking of ridiculous code, I have been slowly write examples for various c# concepts and functionality...
All of this, and none of it actually visibly does a damn thing. In fact at his point all I have done in Unity is make a box move, but I decided to learn the language first so learn it I shall *grumble*
Unity3D is amazing, great, wonderful etc etc
And then you get all excited about having spent all year reading and learning C# in depth like a boss. Having read the entire Unity manual, 100's of articles.... 1000's of articles....
And then... aaaand then... you can't even figure out how to draw a simple rounded rectangle on the screen to make a button. Basic things you take for granted in Flash completely missing in Unity. As Unity really is more of an operating system for making things. And so off you must head to the asset store and goole to find someone else's code to solve this. And then you find dozens of approaches, some long ago abandoned and longer updated, and the best ones no longer developed as Unity snatched the debs up and employed them! How is drawing a simple shape so complicated!
In any case, I decided to create a rounded rectangle in vector style using no bitmap data, found Vectrosity was super good at turn lines into polygons that then draw on the screen to look like well... lines. Nicked some kind to draw circles, put them together in a class and tadda the rounded rectangle drawing class was born:
And yah it has a glitch in it, but otherwise good job team me only took me several days of googling and trying to find a compromise
Ok now to just draw it the size I want and make it fit the width of the screen on ipad/ios etc etc...
Seriously... ok this too is hard apparently!
Which sprite / UI manager do I use, NGUI, SpriteManager, EZGUI..... on and on, oh Unity is bring out a new GUI system... they said a year ago... ok can't wait for that
Screw it, made my own Transform like class with relative scaling, positioning and all that fancy jazz. Took longer than I thought... many days arguably wasted
:-)
Now I need to draw my Logo, but at a different location and scale depending on the screen size, screen dpi.. orientation... oh god, what can of worms is this....
So I write that by having multiple copies of my special Transform and a script that picks which one of those to use based on criteria....
And there you have it, several weeks to get my logo and a rounded rectangle drawn to the screen exactly where I want it
This while making a game thing... could end up taking quite some time I think :-S
In the process made some weird looking stuff!
First attempt at rounded rectangle created some weird bacon like creations:
Rectangles ahoy:
Playtime with procedurally rounded rectangles!, Oh the fun I have:
Tinkered with making 3D looking text:
There are a total of 0 books on advanced Unity 3D with C#
I mean... seriously, what are you doing learning Unity if you need this bit explaining this verbosely:
That explanation did not need to take up that much space
:-D
Speaking of learning to code, it is funny to think how far I have come, even if it feels like I am not moving sometimes
Not long ago something like this would have made me quite emotional:
And now it just makes me screw my face up a bit
( it was complaining because I was using a nullable values represented by question marks. Your chance of figuring that out if you just started C# about the same as == null ?? -1