Blog

Friday, April 9th, 2010

Apple Will Buy Adobe

(I wrote this originally on April 9, 2010 and didn’t have the balls to post it. My prediction still hasn’t come true, but it still could.)

So it’s been a day since my personal Twitterverse, which is comprised heavily of Unity and Flash game devs, exploded into a fearful frenzy over the latest changes to the iPhone developer agreement. It essentially states that apps created for the iDevices must be made entirely with Apple approved methods. There is little doubt that this has to do with the impending release of Flash CS5 and its ability to spit out iPhone apps without involving XCode.

So, my first reaction was “how does this benefit Apple?”. It took a night and a long drive to the DMV today to really come up with a compelling long term strategic theory, but I can see an endgame: Apple is going to buy Adobe.

Why? What? But Apple hates Adobe you say? They hate Flash you say? The only thing that Apple hates is not being in control of their platform, and you can’t blame them for that. But what is upsetting developers so much about this announcement is that Apple is implicitly saying “You cannot use these new, easier methods of developing applications. Instead, you must use our difficult ones.” The irony is that Apple is normally all about being the easier and more intuitive way to use technology… but when it comes to application development, this is just not the case. Their tools suck and are not made for the masses. They are made for those who are solely dedicated to Apple technology.

At the same time, web video is absolutely owned by Flash. HTML5 is neat, and Silverlight is interesting, but to be relevant today, your platform needs to run Flash video. Apple is not stupid. The cards they are playing suggest one of two outcomes – the death of Flash outright, or the purchase of Adobe and Flash through marginalizing Adobe stock, making it a cheap buy. Apple’s market cap is a staggering $218bn USD. Adobe’s is $18bn USD. No matter how damaged Adobe becomes over this, they’ll still hold valuable IP that Apple could use. Think Postscript, PDF, Photoshop… I don’t know how far it goes but there’s much there for Apple to leverage going forward.

As we march forward into the future of Apple’s platform dominance, Adobe knows it is screwed. It’s fighting hard, but without a quantum shift in strategy, it will die. Flash has peaked in its current state and it’s being attacked from multiple vectors – From the tech end by HTML5, from the business end by Apple, and by the developer end by migration to more flexible, powerful, and lucrative paths such as Unity and the iPhone. It would be smart of Adobe to sell. And it would be smart of Apple to not only own Flash, but to own the industry standard content creation tools that Adobe has created.


Saturday, January 16th, 2010

Unity Model Viewer In Progress – Rev 2

An addition to the Model Viewer – Animation switching. The viewer automatically reads the animations on a model and lets the user flip through them. The model is a blockout concept for an in-progress project my buddy Andy and I are tinkering with.


Wednesday, January 6th, 2010

Productivity++ or how I stopped bad browsing habits

Like anyone that works at their computer all day, I have to make a point of staying productive through periods of waiting. Waiting for an app to load, for a file to process, or anything else that takes me out of the Flow, and my habit is to reach for Firefox and pull up Facebook or Digg. These two sites really offer no value during the workday. Zero. Unfortunately they are horribly addictive.

Well, I’ve tried putting extensions on Firefox, but sometimes I’ll end up browsing with Chrome and BAM, before I know it I’m commenting on a photo of someone’s car or reading about the latest LOLCat to set the tubes on fire. Well my New Year’s Resolution was to put an end to this and at the very least start visiting sites that advance my life in some way.

So here’s what I’m doing and it’s working so far. See, most every computer nowadays has a “hosts” file, which takes precedence over  everything in determining how a URL gets mapped to an IP address. By editing it strategically, you can redirect any attempt to visit one site to another. Wikipedia has a nice article on hosts files and how they work, but their links to instructions are poor. Try these instead:

Windows XP/Vista/7: http://www.fpweb.net/support/managed-hosting/hostfile-editing-support.asp

Mac: http://ocaoimh.ie/mac-os-x-how-to-update-etchosts/

Neckbeard

Linux users already know this stuff.

So what you can do with your hosts file is map a site that you want to stop visiting to one that you want to start visiting. If you habitually type digg.com into your browser, then that will get remapped. Here’s what you need to do to map digg.com to answers.unity3d.com (because reading the Unity Answers site will certainly enrich you in some way)

  1. Open up your hosts file per the above instructions
  2. Get the IP address of answers.unity3d.com by opening up a command line/terminal and typing ‘ping answers.unity3d.com’ minus the quotes.  In this case it is 64.34.80.165
  3. In the hosts file, add a line that looks like this:       64.34.80.165   digg.com  #digg->answers.unity3d.com
  4. Then add a line that looks like this:       64.34.80.165   www.digg.com  #digg->answers.unity3d.com
  5. Save the hosts file
  6. Try visiting digg.com and enjoy your self-administered smackdown.

I’ve already found that this has helped me break some bad browsing habits.


Friday, September 18th, 2009

Detonator 1.01 – Indie Fix

Thanks to everyone who pointed out that the initial release of Detonator did not play nice with Unity Indie. The Heatwave and its HeatDistort shader made it quite sad indeed.

Indie users note: After installing this package, delete Detonator/Resources/Detonator/Textures/HeatDistort

Update: Posted 1.02 – The fallback subshader in HeatDistort  was not working properly. Now it is and you don’t need to delete that shader anymore. Woop!

Link: Detonator-1.02


Wednesday, September 16th, 2009

Detonator release today?

Detonator-Finalshots

(Update: Apparently the Unity guys had some issues updating their site. Stuff should be up 9/17)

Well as of this writing it’s not out just yet, but it will be very shortly. I’m going to bed in a few minutes and the boys in Copenhagen will be getting up, and Detonator, if not all of the SOC projects, will be released tomorrow. I wanted to just make a quick post for anyone that ends up here and is looking for more info, wondering where development is headed, or finds bugs.

I plan on continuing development on the project and will be posting the code and the current dev build to some public source sharing service like Assembla.com or Google Code in the next couple of days. I’m SURE that people will find bugs and I’d like to stay on top of them as best I can. Really, there was minimal testing done on this project so if something acts weird, it probably is.

In the meantime, if you find a bug and don’t know what to do with it, drop it in the comments here. Thanks!


Tuesday, September 15th, 2009

Detonator is close…

Detonator Parametric Explosion Framework for Unity from Unity3D on Vimeo.


Saturday, August 22nd, 2009

Detonator – Progress Point 5

Detonator-Logo

(This post is mirrored on the Unity Technologies Blog as well.)

We’re just 9 days away from the August 31 deadline so it’s time for an update. The good news is that it’s almost done, and that means a ton of changes since the first concept Unity players that I posted on my blog (see Point3, Point2, and Point1). The main effort has been towards making Detonator entirely code driven. This involved creating a new particle component (DetonatorBurstEmitter) that calls some of the scriptable functions on the standard Unity particle system, but makes one shot emissions and the other sort of scaling effects easier to create.

So, what about actually using it? The simplest use case is to take a GameObject, attach a Detonator component to it (in code or in the Inspector), and either call Explode() in code or check the “Explode on Start” checkbox in the Inspector. That will do a whole bunch of stuff… create all kinds of emitters, a light, a force, all corresponding default materials, and then BOOM, you’re exploding. That usage case was a primary design goal and it’s met.

Detonator-ProgressShot

If you want to take it one step further, you can tweak parameters on the Detonator component. The default explosion has a 10m radius, and that can be changed to whatever you’d like – all effects scale accordingly. As anyone that works with particle systems knows, this is not a trivial thing because it needs to change particle size, emitter radius, velocity, emitter position, and forces all in unison.

Performance scalability is also a concern with effects, because, well, they can scale.  For that there’s the detail parameter, which affects the number of particles spawned, and even whether or not certain entire sub-components get created. Each piece has a detailThreshold parameter that lets you customize how your Detonator explosion scales to different performance specs. I’ll be looking into how this will hook into the global Unity quality settings as well – no promises for release but I’ll get it in shortly after if it doesn’t make it then.

After detail there’s color. Changing the color of the main Detonator component will have differing effect depending on its alpha value. Since using alpha purely for transparency didn’t make a lot of sense in this context, it instead serves as the color influence. So if you make your color Blue with 50% alpha, then colors of all sub-components will be 50% blended to that blue. Since the normal fireball is orange and other parts are white, this gives a nice non-uniform coloration. By the same token if you’d like to go for a stylized look, crank the alpha to 100%.

Duration can also be adjusted. This was tricky because just altering this naively made the explosions really dim, so the alpha values of all the emitters’ color animations try to stay more opaque when the duration is shorter. Everything is tuned to make changing parameters make sense. Of course, we’ll learn a ton more when people are using this en masse, but I’ve given it my best shot to start with.

So that is the main Detonator component. Many people will just use that, but underneath is a full-fledged explosion construction kit. For instance, DetonatorFireball is one of the sub components that a Detonator normally auto-creates. Instead, you can make your own by  dragging a DetonatorFireball script onto that same GameObject. You can add one, two, or ten of these and then get busy changing their relative positions, sizes, colors. You can even time when they go off (with randomness) to create startling layered effects. Then add some sparks, smoke, a glow, a light, or whatever you want. In just a few minutes I was able to make a pretty nice mushroom cloud. I can’t want to see what people do with this.

Detonator-MushroomCloud

And for the artists out there like myself, you can switch out the materials and textures that your Detonator components use. Either replace them at the top level and let them cascade down to subcomponents, or replace them piece by piece, it’s up to you. I’d really like to see what is possible with stylized or toon explosions with this system.

So what needs to still be done? I still need to reimplement a few components that were in the concept effect… namely the chunk emitter (which sprays any gameobject you’d like with trailing smoke) and the physics force (which acts on rigidbodies and even sets them on fire if you want). The UI of the main Detonator could use some spicing up, but that would mean reimplementing material slots through the drag and drop API, which might not be worth it at this stage. The main thing the UI would do is put buttons in to create each subcomponent so one wouldn’t need to manually drag scripts onto it. It feels like that would add a nice level of polish so I’ll have a look.


Monday, August 3rd, 2009

Detonator Progress Point 3

This version features better particle growth thanks to a tip on particle Size Grow parameter animation courtesy of Rune at Unity. I was having a real problem getting the behavior I was looking for out of the Size Grow parameter, and it turns out that if you alter that parameter over time, you can get the exponential growth with damping that’s needed for an explosion.

I also converted the textures to grayscale so that they can be color shifted by the system. It takes a little bit of the richness out, but I think we can get it back later. The payoff in color customizability will definitely be worth it.

(more…)


Saturday, August 1st, 2009

Detonator Progress Point 2

Well I got some good feedback from the last progress snapshot. We have a mailing list for the various folks to talk and a few of the guys, Rune, Jonas, and Joachim all chimed in with their thoughts on the first go…

So for this update I worked on making the explosions expand better, tweaked some of the color to make things more varied, and added a cool feature where the explosion will automatically ignite any object that it hits through the physics system (thanks Rune for the idea). I also adjusted the background so the smoke is more visible. Also note that the explosion is currently about 10m in diameter… thus the floatiness of the physics. In the end it will be scalable to different sizes, but I figured if we’re gonna start with anything, we’ll start big. :)

Read more to see it in action…

(more…)



All content © Copyright 2013 by Ben Throop.
Subscribe to RSS Feed – Posts or just Comments

Powered by WordPress
Based on a Theme by Graph Paper Press