Are you OK with Purchasing WebGL Add-On?

Do Unity owe you something?

Well, maybe better to ask is, what is your familiarity with webgl? I was messing around with it a couple of years ago using three.js where i'd read the dom of a web-based chatroom and put it into a pretty high poly textured 3D scene. It was running fine on my netbook with the scene composed of a few hundred thousand polygons and the text all written to canvas, grabbed then used as transparent textures on a billboard, letter by letter. It was all animated pretty swankily too. This was 2 years ago and that was running usably on my netbook, i'm not that concerned about webgl's performance or capacity to offer a pleasing result upon working with it, in fact i'm quite confident of it being pretty nifty

With any sort of compatibility with the general concept of a DOM and other elements feasibly being from the loose HTML5 spec being able to work along with the unity element (and executing js from within c# or whatever), webgl gives you far more flexibility than i can think the webplayer ever gave, or could give. Its not some lump of a plugin, if it works like any other webgl element then there are some massive opportunities opened that i thought a web-based project would benefit from endlessly - Really blatantly useful things like grabbing content from elsewhere on the net is explicable in an established web use way. The whole plugin thing is so closed off and crappy, getting folk i know to try out a game can be scuppered at the instant need to go install something on their computer, that alone puts a more natural move into a browser worthwhile.

I'm speculating of course, but the actual power of a webgl based platform, if treated like any other element on a web page far outstrips that of the webplayer, while not alienating or cheapening things to people who are meant to value whatever youre making, i dont see how that should be cheap, or even said in the same context as the webplayer. i might be wrong of course, it happens

So no, i think the best attitude to a webgl investment is positivity and being constructively critical if needed rather than thinking its the end of the world. I like the webplayer cause it lets me show my stuff to people, otherwise i think it's a terrible way to present something to someone and i'd be glad when its gone and i can feasibly think about a webgl license

 

Ahh yeah, and the examples of super groovy content creation software for webgl that Unity should copy because that does webgl too.. come onnnn.... if you actually thought they were at all relevant wouldn't you just go use them instead? The use in Unity and Unreal building to webgl is pretty obvious (right?) you know, all them features and stuff they have

 

Even if the future versions of all major browsers and new mobile devices will support WebGL within a year or two, we all know that it'll take at least five years or more for a large percentage of the population to have those new mobile devices and new versions of browsers. That's a heck of a long time to wait before releasing applications. At least the webplayer is available now, with an estimated installed base in the hundreds of millions (if I'm not mistaken). And at least it's free.
I agree that the _idea_ of WebGL is great; but it'll be quite awhile before it's anything close to a ubiquitous platform.

 

Short answer is no.
Long answer is No.

 

Ok, that's a lot better than I thought, and changes my perception quite a bit. Nonetheless, my copy of Chrome 35 on a nearly brand-new machine doesn't reliably run WebGL apps that are supposed to work with Chrome 23. When they manage to run, they run well; but they often don't run at all. And IE 11 is worse. At least the webplayer works consistently.
But, I understand that Unity wasn't left with any choice in the matter, since browsers are dropping plugin support. But it leaves us with the need to deal with a relatively new system which is guaranteed to have problems for awhile until the various browsers can fix all the bugs, and if it costs $1,500 to replace the free webplayer, that makes it worse.

 

It is a theme constantly repeated here: we see one person who's making $0-$5000 from their $1500 Unity Pro investment (who think it's expensive), another making $50K+ (who thinks it's reasonable), and yet another $500K (who think it's ridiculously cheap).

For me, the WebPlayer mostly delivers the demo for my game - I make very little off that compared to the Steam build (using Unity Desktop), yet it could cost me the same on top. Others conversely complain about having to buy Desktop (from which they make $0) to get to iOS and/or Android Unity (and here now Web).

It would be a strange democracy that taxed the poor $10000/year and the wealthy also $10000/year - the poor man would find this onerously harsh, while the rich man would laugh!

No fixed price point can come close to working for everyone, neither any bracketing of functionality - either on the Pro/non-Pro axis or the platform axis (or even the source vs. no-source axis).

The whole notion of chopping Unity up into bits and trying to sell each as an Add On doesn't make a lot of sense to me. Developers should be encouraged to port their games to other platforms for additional revenue - on the principle that customer success leads to more vendor success. But since UT doesn't make any income based on customer's success, there is no motivation.

 

I'd like to cast my vote that WebGL should be 'free' in stock Unity. The reasons can be covered forever, it is merely the expectation of the world, that Unity has web export as part of the baseline package.

Logic dictates that because top browsers will soon only support WebGL, it means that Unity can no longer offer web player for those browsers. This is not like flash. We are talking about baseline browser support. WebGL will be the only option for this.

Therefore I would not expect WebGL to be a paid addon.

 

The poll needs a 3rd option:

3: I'm not currently interested in WebGL, so I'd prefer not to be subsidising it's development.

Personally, I'd be surprised if the WebGL support is much good - it seems likely to be plagued with performance and browser compatibility issues (as almost everything HTML5/WebGL is at the moment). But the technologies are moving forward at a fair pace, so it might be fairly good in the long term.

Can't see it being viable on mobile in the next 5 years, though - not in any way that competes with native apps, at least. 'Compiling to Javascript' doesn't seem like something that will ever by good for performance, no matter how many clever hacks and bodges (e.g. ASM.js) are involved...

And even if performance becomes more viable due to better hardware, a compiled-to-Javascript app is always going to consume more battery power than a well-written native app.

 

I don't like their whole add-on pricing model. Each add-on shouldn't be the same price as host application.

 

@bluescrn you do understand that most Javascript browser engines are starting to use AOT compilation, so the javascript is compiled Ahead of Time (of use) to native code then triggered when called.

And currently you are using monos JIT compilation system (depending on platform) so you are probably not running native code.

Personally I think Unity will be shooting itself in the foot by not bundling WebGL as a default and Free build target. It has improved 2D capabilities, decent 3D and will have a working built in GUI system and the improvements due in 5.

WebGL is opening up collaborative 3D online building tools and game engines, these are the quick fast web tech startups and players in the space.

So Unity will have lots of low level competition, as well as high level competition from the AAA game engines.

If Unity wants to stay competitive and adapt to the changing landscape I think it needs a Free WebGL option built-in IMHO.

 

But the entire Unity engine - including the performance-critical rendering/physics/audio systems, are written in native code.

For HTML5/WebGL, all of that must be 'compiled' to Javascript!

 

Well I think the way it works is Unity use a Mono bytecode to C converter, then use the asm.js "compiler" to generate the javascript. And that is loaded by the browser and depending on how the browser works with javascript, it will either run it via a Virtual Machine or Compile it into native code.

But the WebGL rendering pipeline, like the DirectX/OpenGL rendering pipeline will be a native driver built into the browser as will the audio. But the physics system is probably going to be the biggest hit for performance, unless Unity can figure out how to move that onto the GPU's via WebCL.

Probably the biggest issue is your game depending on the browsers javascript engine and therefore could be limited to run in a single thread, even if AOT or JIT compiled to native code.

 

The following spec from the Kronos Group (http://www.khronos.org/registry/webgl/specs/1.0/#4.3 ) says that WebGL shaders are limited to the terms in the following document, Appendix A, sections 4 & 5: http://www.khronos.org/registry/gles/specs/2.0/GLSL_ES_Specification_1.0.17.pdf

Which would mean that you can't have true branching (IF statements need to be limited to using a static # of iterations, and while loops aren't allowed at all). It doesn't say whether subroutine calls are allowed, but I'm guessing that they wouldn't.
If this is accurate, it would place severe restrictions on shaders.

 

We'd best get used to it then if we want to support web in future. This is pretty trivial for any mobile dev as branching in shaders is a big no-no. You can use Step func to get around that in most cases.

 

https://www.khronos.org/webgl/

"WebGL is a cross-platform, royalty-free web standard for a low-level 3D graphics API based on OpenGL ES 2.0, exposed through the HTML5 Canvas element as Document Object Model interfaces"

People should have no concern about the power of the shading language but the stability and cross platform consistency.
From what I see, webgl is a mess because of the lower layers... Unity will have to deal with all this.
"This doesnt work on that driver on nvidia HW & chrome on windows... and that doesn't work on android on Adreno.. etc.. etc.."

 

Youtube participates, so that site is probably a very, very good indicator.

 

Can't the browser just suspend a process if it truly bogs down too long, rather than forbidding all shaders that use flow-control options from modern shader models? It's a little surreal for the Khronos Group to forbid all use of dynamic flow control, basically throwing us back to SM 2.0.

 

Well, I meant it could suspend the webpage. But many webpages currently cause my browser to hang because the browser normally doesn't forbid potentially troublesome techniques for anything else, so I don't understand why Khronos thinks WebGL shaders need to be an exception to the normal "user beware" policy. In other words, if a WebGL program gums up the browser, the user just has to manually shut it down as with anything else that gums up the browser. Why do they need to adopt a double standard with this?

Forcing us to use SM 2.0 flow-control is just bizarre.

 

I think most people used the web publisher as a convenience rather than an actual platform. The people that did actually intend to use it as a target platform probably intended to make enough money that it justified paying for it.

No one complains when features are added to the Free package like Navmesh, Dir light shadows, Mecanim, uGUI, etc... so for me I don't really take issue with WebGL being a paid addon. Web is a target platform like iOS, Android, Windows, Linux, W8, etc... If it came down to the wire I'd much rather see WebGL as a paid addon than see some of the cool features in the 5.x cycle be taken out of the Free users' hands.

If it does end up being a paid asset, we'll probably see much less Unity Web games and demos than there currently are, which is unfortunate because its so handy to be able to push out a webplayer on dropbox at the snap of your fingers.

I think Hippo made a smart comment here...

It's always been there, and people expect it to always be there. Despite the changing environment most people are going to feel that it was 'taken out' of the base Unity package. Maybe they're worried about scaling up their existing projects and can't upgrade to 5.x or whatever because of it but really, they're screwed in a year anyway because of plugin support being sliced and thats not the fault of UT, at least there is a mainstream alternative being given.

 

I don't know if it's been said before but is a similar approach to webgl as the android and ios options available in free being taken? Has this been proposed or discussed? It seems like a no brainer? Are there reasons i am wrong?

 

At work we use it for a lot of both. It's an easy way to get a WIP to a client, and some clients want stuff delivered in-browser and are happy to install the plugin.

 

It has also been the main method of showing demos to people on this forum.

 

Sure, but there are also huge limitations if we are prevented from using modern flow-control, especially since it's such a basic type of functionality. Has Unity tried to talk the Kronos Group into changing these restrictions?
BTW, I assume we're not prevented from using real subroutine calls? I assume we aren't, but the guidelines didn't make this completely clear.

 

Example of webgl code
https://www.shadertoy.com/view/XsfGWj

(This run on my android tablet with Chrome)


But now browse this site... and you will see that many pixel shaders dont work and this or that browser, and this or that driver, and this or that GPU card, etc..

Code (CSharp):

1. // Ben Weston - 15/08/2013
2.  
3. /*
4. Eye ball effects:
5. • Ray-marched shape
6. • Ray-traced iris refraction
7. • Fake photon mapping on iris
8. • Subsurface scattering on sclera
9. • HDR reflections with fresnel
10. • Eyelid reflection occlusion
11. • Eyelid ambient occlusion
12. • Procedural textures
13. • Procedural animation
14. */
15.  
16. // KEY CONTROLS - (click on eye to give keyboard focus)
17. const int Key_M = 77; // mouse controls camera / eye direction
18.  
19. const int Key_E = 69; // refraction on/off
20. const int Key_P = 80; // photon mapping on/off
21. const int Key_L = 76; // change photon mapping technique (both fake, but one is imitating reality and the other is prettier)
22.  
23. const int Key_S = 83; // subsurface scattering on/off
24. const int Key_A = 65; // ambient occlusion on/off
25.  
26. const int Key_R = 82; // reflection on/off
27. const int Key_O = 79; // reflection eyelid occlusion on/off
28.  
29. const int Key_C = 67; // iris colour
30. const int Key_N = 78; // iris normal
31.  
32.  
33. // Lights
34. #if (1)
35.     // High-contrast light edge-on
36.     const vec3 lightDir = vec3(-2,2,.5);
37.     const vec3 lightColour = vec3(1.0);
38.     const vec3 fillLightDir = vec3(0,1,0);
39.     const vec3 fillLightColour = vec3(.65,.7,.8)*.7;//vec3(.15,.2,.25);
40. #else
41.     // more neutral "good" lighting (doesn't show off the effects)
42.     const vec3 lightDir = vec3(-2,2,-1);
43.     const vec3 lightColour = vec3(.83,.8,.78);
44.     const vec3 fillLightDir = vec3(0,1,0);
45.     const vec3 fillLightColour = vec3(.65,.7,.8);
46. #endif
47.  
48.  
49.  
50. // Constants
51. const float tau = 6.28318530717958647692;
52.  
53. // Forward declarations
54. float Noise( in vec3 x );
55. vec2 Noise2( in vec3 x );
56.  
57.  
58.  
59. // Gamma correction
60. #define GAMMA (2.2)
61.  
62. vec3 ToLinear( in vec3 col )
63. {
64.     // simulate a monitor, converting colour values into light values
65.     return pow( col, vec3(GAMMA) );
66. }
67.  
68. vec3 ToGamma( in vec3 col )
69. {
70.     // convert back into colour values, so the correct light will come out of the monitor
71.     return pow( col, vec3(1.0/GAMMA) );
72. }
73.  
74.  
75. // key is javascript keycode: http://www.webonweboff.com/tips/js/event_key_codes.aspx
76. bool ReadKey( int key, bool toggle )
77. {
78.     float keyVal = texture2D( iChannel3, vec2( (float(key)+.5)/256.0, toggle?.75:.25 ) ).x;
79.     return (keyVal>.5)?true:false;
80. }
81.  
82.  
83. // ------- EDIT THESE THINGS! -------
84.  
85. // Camera (also rotated by mouse)
86. const vec3 CamPos = vec3(0,0.0,-250.0);
87. const vec3 CamLook = vec3(0,0,0);
88. const float CamZoom = 10.0;
89. const float NearPlane = 0.0; // actually not needed
90. const float drawDistance = 1000.0;
91.  
92. const vec3 SkyColour = vec3(.4,.25,.2);//fillLightColour*.5;//vec3(.1,.3,.5);
93.  
94. vec3 SkyDome( vec3 rd )
95. {
96.     //the cube maps have lines in, and aren't HDR, so make our own shapes
97.    
98.     // random variation
99.     vec3 result = ToLinear(SkyColour)*2.0*Noise(rd);
100.    
101.     // square sky-light
102.     result = mix( result, vec3(8), smoothstep(.8,1.0,rd.y/max((rd.x+1.0),abs(rd.z))) );
103.  
104.     return result;
105. }
106.  
107. // Eye params
108. const float IrisAng = tau/12.0;
109. const float PupilAng = (1.6*IrisAng/5.0);
110. const float EyeRadius = 10.0;
111. const float BulgeRadius = 6.0; // used for photon trace, must be bigger than EyeRadius*sin(IrisAng)
112.  
113.  
114. vec4 ComputeEyeRotation()
115. {
116.     vec2 rot;
117.     if ( !ReadKey( Key_M, true ) && iMouse.w > .00001 )
118.         rot = .25*vec2(1.0,1.0)*tau*(iMouse.xy-iResolution.xy*.5)/iResolution.x;
119.     else
120.     {
121.         float time = iGlobalTime/2.0;
122.         time += Noise(vec3(0,time,0)); // add noise to time (this adds SO MUCH character!)
123.         float flick = floor(time)+smoothstep(0.0,0.05,fract(time));
124.         rot = vec2(.2,.1)*tau*(texture2D( iChannel0, vec2((flick+.5)/256.0,.5), -100.0 ).rb-.5);
125.     }
126.    
127.     return vec4(cos(rot.x),sin(rot.x),cos(rot.y),sin(rot.y));
128. }
129.  
130.  
131. vec3 ApplyEyeRotation( vec3 pos, vec4 rotation )
132. {
133.     pos.yz = rotation.z*pos.yz + rotation.w*pos.zy*vec2(1,-1);
134.     pos.xz = rotation.x*pos.xz + rotation.y*pos.zx*vec2(1,-1);
135.    
136.     return pos;
137. }
138.    
139.  
140.  
141. // Shape
142. // This should return continuous positive values when outside and negative values inside,
143. // which roughly indicate the distance of the nearest surface.
144. float Isosurface( vec3 pos, vec4 eyeRotation )
145. {
146.     pos = ApplyEyeRotation(pos,eyeRotation);
147.    
148. /*    float f = length(pos)-EyeRadius;
149.    
150. //    f += Noise(pos*3.0)*.008;
151.  
152.     // cornea bulge
153.     float o = EyeRadius*cos(IrisAng)-sqrt(BulgeRadius*BulgeRadius-EyeRadius*EyeRadius*pow(sin(IrisAng),2.0));
154.     float g = length(pos-vec3(0,0,-o))-BulgeRadius;
155.  
156. //g += Noise(pos/2.0)*.5;
157.  
158.     return min(f,g);
159.     //return -log(exp(-g*2.0)+exp(-f*2.0))/2.0;*/
160.    
161.     vec2 slice = vec2(length(pos.xy),pos.z);
162.    
163.     float aa = atan(slice.x,-slice.y);
164.     float bulge = cos(tau*.2*aa/IrisAng);
165.     bulge = bulge*.8-.8;
166.     bulge *= smoothstep(tau*.25,0.0,aa);
167.    
168.     // sharp-edged bulge
169. //    if ( aa < IrisAng )
170. //        bulge += cos(tau*.25*aa/IrisAng)*.5;
171.     bulge += cos(tau*.25*aa/IrisAng)*.5 * smoothstep(-.02,.1,IrisAng-aa); // slightly softer
172.    
173.     return length(slice) - EyeRadius - bulge;
174. }
175.  
176.  
177.  
178. float GetEyelidMask( vec3 pos, vec4 eyeRotation )
179. {
180.     vec3 eyelidPos = pos;
181.     float eyelidTilt = -.05;
182.     eyelidPos.xy = cos(eyelidTilt)*pos.xy + sin(eyelidTilt)*pos.yx*vec2(1,-1);
183.    
184.     float highLid = tan(max(tau*.05,asin(eyeRotation.w)+IrisAng+.05));
185.     float lowLid = tan(tau*.1);
186.    
187.     float blink = smoothstep(.0,.02,abs(Noise(vec3(iGlobalTime*.2,0,0))-.5 ));
188.     highLid *= blink;
189.     lowLid *= blink;
190.    
191.     return min(
192.                 (-eyelidPos.z-2.0) - (-eyelidPos.y/lowLid),
193.                 (-eyelidPos.z-2.0) - (eyelidPos.y/highLid)
194.             );
195. }
196.    
197. float GetIrisPattern( vec2 uv )
198. {
199.     return Noise( vec3( 10.0*uv/pow(length(uv),.7), 0 ) );
200. }
201.  
202. // Colour
203. vec3 Shading( vec3 worldPos, vec3 norm, float shadow, vec3 rd, vec4 eyeRotation )
204. {
205.     vec3 view = normalize(-rd);
206.  
207.     // eyelids - just match BG colour
208.     float eyelidMask = GetEyelidMask(worldPos, eyeRotation);
209.    
210.     if ( eyelidMask < 0.0 || (-worldPos.z-3.0) < (worldPos.x/tan(tau*.23)) )
211.     {
212.         return ToLinear(SkyColour);
213.     }
214.    
215.     vec3 pos = ApplyEyeRotation(worldPos,eyeRotation);
216.    
217.     float lenposxy = length(pos.xy);
218.     float ang = atan(lenposxy/(-pos.z));
219.     if ( ang < 0.0 )
220.         ang += tau/2.0;
221.    
222.  
223.     // refract ray
224.     vec3 irisRay = ApplyEyeRotation(-view,eyeRotation);
225.     vec3 localNorm = ApplyEyeRotation(norm,eyeRotation);
226.     float a = dot(irisRay,localNorm);
227.     float b = cos(acos(a)*1.33);
228.     if ( !ReadKey( Key_E, true ) )
229.         irisRay += localNorm*(b-a);
230.     irisRay = normalize(irisRay);
231.    
232.     // intersect with plane
233.     float planeDist = -cos(IrisAng)*EyeRadius;
234.     float t = (planeDist-pos.z)/irisRay.z;
235.  
236.     vec3 ppos = t*irisRay+pos;
237.  
238.  
239.     // polar coord map
240.     float rad = length(ppos.xy);
241.     float pupilr = EyeRadius*sin(PupilAng);
242.     float irisr = EyeRadius*sin(IrisAng);
243.    
244.     float irisPattern = GetIrisPattern(ppos.xy); // reduce contrast of this now we have actual lighting!
245.  
246. /*    vec3 iris = mix( mix( vec3(.3,.1,.1)*.5+.5*vec3(.6,.4,.1), vec3(.6,.4,.1), irisPattern ), // hazel
247.                     mix( vec3(.2,.2,.2)*.5+.5*vec3(.5,.45,.2), vec3(.5,.45,.2), irisPattern ),*/
248.  
249. /*    vec3 iris = mix( mix( vec3(.1,.1,.4), vec3(.7,.9,1), irisPattern ), // blue
250.                     mix( vec3(.1,.1,.4), vec3(.3,.4,.7), irisPattern ),*/
251.  
252. //                    smoothstep(pupilr*2.0,irisr,rad));
253.  
254.     vec3 iris = ToLinear( mix( pow( vec3(.65,.82,.85), 2.0*vec3(1.2-sqrt(irisPattern)) ),
255.                     vec3(1,.5,.2), .7*pow( mix( smoothstep(pupilr,irisr,rad), Noise(ppos), .7), 2.0) ));
256.  
257.     if ( ReadKey( Key_C, true ) )
258.         iris = vec3(1);
259.  
260.     // darken outer
261.     iris *= pow( smoothstep( irisr+1.0, irisr-1.5, rad ), GAMMA );
262.  
263.  
264.     vec3 irisNorm;
265.     irisNorm.x = GetIrisPattern(ppos.xy+vec2(-.001,0)) - GetIrisPattern(ppos.xy+vec2(.001,0));
266.     irisNorm.y = GetIrisPattern(ppos.xy+vec2(0,-.001)) - GetIrisPattern(ppos.xy+vec2(0,.001));
267.  
268.     // add a radial lump
269.     irisNorm.xy += -.01*normalize(ppos.xy)*sin(1.*tau*rad/irisr);
270.  
271.     irisNorm.z = -.15; // adjust severity of bumps
272.     irisNorm = normalize(irisNorm);
273.  
274.     if ( ReadKey( Key_N, true ) )
275.         irisNorm = vec3(0,0,-1);
276.        
277.  
278.     // lighting
279.     // fake photon mapping by crudely sampling the photon density
280.  
281.     // apply lighting with this modified normal
282.     vec3 lightDirN = normalize(lightDir);
283.     vec3 localLightDir = ApplyEyeRotation(lightDirN,eyeRotation);
284.  
285.     vec3 fillLightDirN = normalize(fillLightDir);
286.     vec3 localFillLightDir = ApplyEyeRotation(fillLightDirN,eyeRotation);
287.  
288.     // Bend the light, imitating results of offline photon-mapping
289.     // Jimenez's paper makes this seem very complex, because their mapping used a non-flat receiver
290.     // but the self-shadowing was negligible, so the main effect was just like premultiplying by a normal
291.     // where we'd get better results by using the actual normal.
292.  
293.     float photonsL, photonsFL;
294.  
295.     if ( !ReadKey( Key_P, true ) )
296.     {
297.         if ( !ReadKey( Key_L, true ) )
298.         {
299.             // Nice retro-reflective effect, but not correct
300.             vec3 nn = normalize(vec3( ppos.xy, -sqrt(max(0.0,BulgeRadius*BulgeRadius-rad*rad)) ));
301.            
302.             vec3 irisLDir = localLightDir;
303.             vec3 irisFLDir = localFillLightDir;
304.         //    irisLDir.z = -cos(acos(-irisLDir.z)/1.33); // experiments showed it cuts out at 120 degrees, i.e. 1.33*the usual 90 degree cutoff
305.         //    irisFLDir.z = -cos(acos(-irisFLDir.z)/1.33); // experiments showed it cuts out at 120 degrees, i.e. 1.33*the usual 90 degree cutoff
306.             float d = dot(nn,irisLDir);
307.             irisLDir += nn*(cos(acos(d)/1.33) - d);
308.             d = dot(nn,irisFLDir);
309.             irisFLDir += nn*(cos(acos(d)/1.33) - d);
310.             irisLDir = normalize(irisLDir);
311.             irisFLDir = normalize(irisFLDir);
312.             photonsL = smoothstep(0.0,1.0,dot(irisNorm,irisLDir)); //soften terminator
313.             photonsFL = (dot(irisNorm,irisFLDir)*.5+.5);
314.             //Seriously, this^ looks really nice, but not like reality. Bah!
315.        
316.         /* reverse it, to make it look a lot like the accurate version - meh
317.             vec3 nn = normalize(vec3( -ppos.xy, -sqrt(max(0.0,BulgeRadius*BulgeRadius-rad*rad)) ));
318.            
319.             vec3 irisLDir = localLightDir;
320.             vec3 irisFLDir = localFillLightDir;
321.             float d = dot(nn,irisLDir);
322.             irisLDir += nn*(cos(acos(d)/1.33) - d);
323.             d = dot(nn,irisFLDir);
324.             irisFLDir += nn*(cos(acos(d)/1.33) - d);
325.             irisLDir = normalize(irisLDir);
326.             irisFLDir = normalize(irisFLDir);
327.            
328.             float photonsL = smoothstep(0.0,1.0,dot(irisNorm,irisLDir)); // soften the terminator
329.             float photonsFL = (dot(irisNorm,irisFLDir)*.5+.5);
330.         */
331.    
332.         }
333.         else
334.         {
335.             //this is a reasonable match to the dark crescent effect seen in photos and offline photon mapping, but it looks wrong to me.
336.             vec3 irisLDir = localLightDir;
337.             vec3 irisFLDir = localFillLightDir;
338.             irisLDir.z = -cos(acos(-irisLDir.z)/1.5); // experiments showed it cuts out at 120 degrees, i.e. 1.33*the usual 90 degree cutoff
339.             irisFLDir.z = -cos(acos(-irisFLDir.z)/1.5); // experiments showed it cuts out at 120 degrees, i.e. 1.33*the usual 90 degree cutoff
340.             irisLDir = normalize(irisLDir);
341.             irisFLDir = normalize(irisFLDir);
342.        
343.             photonsL = smoothstep(0.0,1.0,dot(irisNorm,irisLDir)); // soften the terminator
344.             photonsFL = (dot(irisNorm,irisFLDir)*.5+.5);
345.        
346.             // dark caustic ring
347.             photonsL *= .3+.7*smoothstep( 1.2, .9, length(ppos.xy/irisr+.2*irisLDir.xy/(irisLDir.z-.05)) );
348.         //    photonsFL *= ...;
349.         }
350.     }
351.     else
352.     {
353.         // no photons
354.         photonsL = max( 0.0, dot(irisNorm,localLightDir) );
355.         photonsFL = .5+.5*dot(irisNorm,localLightDir);
356.     }
357.        
358.     vec3 l = ToLinear(lightColour)*photonsL;
359.     vec3 fl = ToLinear(fillLightColour)*photonsFL;
360.  
361.     vec3 ambientOcclusion = vec3(1);
362.     vec3 eyelidShadow = vec3(1);
363.     if ( !ReadKey( Key_A, true ) )
364.     {
365.         // ambient occlusion on fill light
366.         ambientOcclusion = mix( vec3(1), ToLinear(vec3(.8,.7,.68)), pow(smoothstep( 5.0, 0.0, eyelidMask ),1.0) );
367.        
368.         // shadow on actual light
369.         eyelidShadow = mix( vec3(1), ToLinear(vec3(.8,.7,.68)), smoothstep( 2.0, -2.0, GetEyelidMask( worldPos+lightDir*1.0, eyeRotation ) ) );
370.     }
371.     fl *= ambientOcclusion;
372.     l *= eyelidShadow;
373.    
374.     iris *= l+fl;
375.  
376.     // darken pupil
377.     iris *= smoothstep( pupilr-.01, pupilr+.5, rad );
378.  
379.  
380.     // veins
381.     float theta = atan(pos.x,pos.y);
382.     theta += Noise(pos*1.0)*tau*.03;
383.     float veins = (sin(theta*60.0)*.5+.5);
384.     veins *= veins;
385.     veins *= (sin(theta*13.0)*.5+.5);
386.     veins *= smoothstep( IrisAng, tau*.2, ang );
387.     veins *= veins;
388.     veins *= .5;
389.    
390.     vec3 sclera = mix( ToLinear(vec3(1,.98,.96)), ToLinear(vec3(.9,.1,0)), veins );
391.  
392.     float ndotl = dot(norm,lightDirN);
393.    
394.     // subsurface scattering
395. //    float subsurface = max(0.0,-2.0*ndotl*EyeRadius);
396. //    l = pow(ToLinear(vec3(.5,.3,.25)),vec3(subsurface*.2)); // more intense the further light had to travel
397.  
398.     // fake, because that^ approximation gives a hard terminator
399.     l = pow(ToLinear(vec3(.5,.3,.25)), vec3(mix( 3.0, 0.0, smoothstep(-1.0,.2,ndotl) )) );
400.    
401.     if ( ReadKey( Key_S, true ) )
402. //        l = mix( l, vec3(max(0.0,ndotl)), 0.5 );
403. //    else
404.         l = vec3(max(0.0,ndotl));
405.  
406.     l *= ToLinear(lightColour);
407.    
408.     fl = ToLinear(fillLightColour)*(dot(norm,fillLightDirN)*.5+.5);
409.  
410.     fl *= ambientOcclusion;
411.     l *= eyelidShadow;
412.    
413.    
414.     sclera *= l+fl;
415.  
416.     // blend between them
417.     float blend = smoothstep(-.1,.1,ang-IrisAng);
418.     vec3 result = mix(iris,sclera,blend);
419.  
420.    
421.     // eyelid ambient occlusion/radiosity
422. //    if ( !ReadKey( Key_A, true ) )
423.         //result *= mix( vec3(1), ToLinear(vec3(.65,.55,.55)), exp2(-eyelidMask*2.0) );
424. //        result *= mix( vec3(1), ToLinear(vec3(.8,.7,.68)), pow(smoothstep( 5.0, 0.0, eyelidMask ),1.0) );
425.    
426.    
427.     // bumps - in specular only to help sub-surface scattering look smooth
428.     vec3 bumps;
429.     bumps.xy = .7*Noise2( pos*3.0 );
430.     bumps.z = sqrt(1.0-dot(bumps.xy,bumps.xy));
431.  
432.     bumps = mix( vec3(0,0,1), bumps, blend );
433.    
434.     norm.xy += bumps.xy*.1;
435.     norm = normalize(norm);
436.    
437.     float glossiness = mix(.7,1.0,bumps.z);
438.    
439.     // reflection map
440.     float ndoti = dot( view, norm );
441.     vec3 rr = -view+2.0*ndoti*norm;
442.     vec3 reflection = SkyDome( rr );
443.    
444.     // specular
445.     vec3 h = normalize(view+lightDir);
446.     float specular = pow(max(0.0,dot(h,norm)),2000.0);
447.  
448.     // should fresnel affect specular? or should it just be added?
449.     reflection += specular*32.0*glossiness*ToLinear(lightColour);
450.  
451.     // reflection of eyelids
452.     //float eyelidReflection = smoothstep( 1.8, 2.0, eyelidMask );
453.     // apply some parallax (subtle improvement when looking up/down at eye)
454.     float eyelidReflection = smoothstep( .8, 1.0, GetEyelidMask( normalize(worldPos + rd*2.0)*EyeRadius, eyeRotation ) );
455.     if ( !ReadKey( Key_O, true ) )
456.         reflection *= eyelidReflection;
457.  
458.     // fresnel
459.     float fresnel = mix(.04*glossiness,1.0,pow(1.0-ndoti,5.0));
460.  
461.     if ( !ReadKey( Key_R, true ) )
462.         result = mix ( result, reflection, fresnel );
463.  
464.  
465.     //anti-alias the edge
466.     float mask2 = min( eyelidMask, (-worldPos.z-3.0) - (worldPos.x/tan(tau*.23)) );
467.     result = mix( ToLinear(SkyColour), result, smoothstep(.0,.3,mask2) );
468.    
469.     return result;
470. }
471.  
472.  
473. // Precision controls
474. const float epsilon = .003;
475. const float normalPrecision = .1;
476. const float shadowOffset = .1;
477. const int traceDepth = 100; // takes time
478.  
479.  
480.  
481. // ------- BACK-END CODE -------
482.  
483. vec2 Noise2( in vec3 x )
484. {
485.     vec3 p = floor(x.xzy);
486.     vec3 f = fract(x.xzy);
487.     f = f*f*(3.0-2.0*f);
488. //    vec3 f2 = f*f; f = f*f2*(10.0-15.0*f+6.0*f2);
489.  
490.     vec2 uv = (p.xy+vec2(37.0,17.0)*p.z) + f.xy;
491.     vec4 rg = texture2D( iChannel0, (uv+0.5)/256.0, -100.0 );
492.     return mix( rg.yw, rg.xz, f.z );
493. }
494.        
495. float Noise( in vec3 x )
496. {
497.     return Noise2(x).x;
498. }
499.  
500. float Trace( vec3 ro, vec3 rd, vec4 eyeRotation )
501. {
502.     float t = 0.0;
503.     float dist = 1.0;
504.     for ( int i=0; i < traceDepth; i++ )
505.     {
506.         if ( abs(dist) < epsilon || t > drawDistance || t < 0.0 )
507.             continue;
508.         dist = Isosurface( ro+rd*t, eyeRotation );
509.         t = t+dist;
510.     }
511.    
512.     return t;//vec4(ro+rd*t,dist);
513. }
514.  
515. // get normal
516. vec3 GetNormal( vec3 pos, vec4 eyeRotation )
517. {
518.     const vec2 delta = vec2(normalPrecision, 0);
519.    
520.     vec3 n;
521.  
522. // it's important this is centred on the pos, it fixes a lot of errors
523.     n.x = Isosurface( pos + delta.xyy, eyeRotation ) - Isosurface( pos - delta.xyy, eyeRotation );
524.     n.y = Isosurface( pos + delta.yxy, eyeRotation ) - Isosurface( pos - delta.yxy, eyeRotation );
525.     n.z = Isosurface( pos + delta.yyx, eyeRotation ) - Isosurface( pos - delta.yyx, eyeRotation );
526.     return normalize(n);
527. }              
528.  
529. // camera function by TekF
530. // compute ray from camera parameters
531. vec3 GetRay( vec3 dir, float zoom, vec2 uv )
532. {
533.     uv = uv - .5;
534.     uv.x *= iResolution.x/iResolution.y;
535.    
536.     dir = zoom*normalize(dir);
537.     vec3 right = normalize(cross(vec3(0,1,0),dir));
538.     vec3 up = normalize(cross(dir,right));
539.    
540.     return dir + right*uv.x + up*uv.y;
541. }
542.  
543. void main(void)
544. {
545.     vec2 uv = gl_FragCoord.xy / iResolution.xy;
546.  
547.     vec3 camPos = CamPos;
548.     vec3 camLook = CamLook;
549.  
550.     vec2 camRot = .5*tau*(iMouse.xy-iResolution.xy*.5)/iResolution.x;
551.     if ( !ReadKey( Key_M, true ) )
552.         camRot = vec2(0,0);
553.     camPos.yz = cos(camRot.y)*camPos.yz + sin(camRot.y)*camPos.zy*vec2(1,-1);
554.     camPos.xz = cos(camRot.x)*camPos.xz + sin(camRot.x)*camPos.zx*vec2(1,-1);
555.    
556.     vec4 eyeRotation = ComputeEyeRotation();
557.    
558.     if ( Isosurface(camPos, eyeRotation) <= 0.0 )
559.     {
560.         // camera inside ground
561.         gl_FragColor = vec4(0,0,0,0);
562.         return;
563.     }
564.  
565.     vec3 ro = camPos;
566.     vec3 rd;
567.     rd = GetRay( camLook-camPos, CamZoom, uv );
568.    
569.     ro += rd*(NearPlane/CamZoom);
570.    
571.     rd = normalize(rd);
572.    
573.     float t = Trace(ro,rd,eyeRotation);
574.  
575.     vec3 result = ToLinear(SkyColour);
576.     if ( t > 0.0 && t < drawDistance )
577.     {
578.         vec3 pos = ro+t*rd;
579.            
580.         vec3 norm = GetNormal(pos,eyeRotation);
581.        
582.         // shadow test
583.         float shadow = 1.0;
584.         if ( Trace( pos+lightDir*shadowOffset, lightDir, eyeRotation ) < drawDistance )
585.             shadow = 0.0;
586.        
587.         result = Shading( pos, norm, shadow, rd, eyeRotation );
588.        
589.         // fog
590. //        result = mix ( SkyColour, result, exp(-t*t*.0002) );
591.     }
592.  
593.     gl_FragColor = vec4( ToGamma( result ), 1.0 );
594. }

 

Yup.... and in fact it usually takes me several clicks of the reload button to get any given page to work at any given moment.
But here's some really spectacular shaders from that website, all of them using raymarching and nothing but math to produce complex, lifelike animated (!!!) models of a fish and dolphin swimming, and a table with fruit (which also has code for realtime accurate raymarched reflections, but the author had to comment it out because -- yes -- it doesn't compile with WebGL. Hence my complaints about the limitations):

Fish swimming: https://www.shadertoy.com/view/ldj3Dm
Dolphin swimming and leaping out of the waves: https://www.shadertoy.com/view/4sS3zG
Fruit on a table: https://www.shadertoy.com/view/ldl3zl

If they don't work at first (and they probably won't), hit reload a few times until they do. They may also run slowly unless you close all other tabs / restart your browser / shut down all other programs (etc). They sometimes run at close to 60 fps on my machine, but other times they run at less than one (1) fps. This type of inconsistency and flakiness is what drives me nuts about WebGL, and makes me wonder whether it's a viable option for the average user. If it works badly on my brand-spanking-new machine with a decent video card, how is it going to run on older machines?

 

Shadertoy is generally a really bad example of how to do anything with shaders.

Most Shadertoy demos are pushing pixel shaders excessively hard 'just for fun'/'because you can' (and a Shadertoy link seems a near-guaranteed way to crash Firefox on a laptop...). Demos on there aren't at all representative of real-world use of shaders in well-optimized games.

 

Sure, but I'm currently using pretty hefty shaders in my own project.

 

Only way I could see someone feeling as if they were owed something by Unity is if Unity removed the web player after someone purchased Unity Pro with the belief that they could develop for the web, with full access to the features of Pro, for only $1500.

 

I think Waz is about right, nailed right on the spot. Unity Technology (UT) seems to be loosing its north at this one. It is my humble opinion that to democratize game development somehow is not in accordance to decisions about WebGL distribution and thus the future of the web browser platform. Waz explained already the 'why' behind this. I hope the situation will change for actual release. This decision will not only end up holding back developers from widely adopting WebGL (and put pressure thus over vendors to make it better, since it will end up becoming more widely used world wide because of Unity developers pushing towards it) but also end up an opportunity door that silently close for UT... In my opinion UT should make WebGL licensing 'feature based' instead, you already confirmed that's the best way to go. Made Pro features on a separate WebGL add-on for Unity so that you can get revenue from those instead. This should end up solving the issues of UT capitalizing and will also keep the company at good stance with Indies of all kind of budget / earnings.

 

Web player functionality will likely be completely crippled by the end of the year with Chrome removing support.

 

It still works in Firefox doesn't it? Chrome does seem to have a large portion of the market, but they're not the sole browser out there. I know I use both Chrome and Firefox. If something fails to work in one, I open the other.

My point was more if Unity were completely abandoning their web player. Which is probably going to happen eventually.

 

Firefox will likely be following suit. They've already moved pretty much every plugin to click-to-play and there's pushes to make it so you have to manually enable things like the Unity web player in the settings. The era of plugins is winding down, which is likely why HTML5 is even being considered.

 

yay! =)

 

Awesome ... you guys made the right choice. Glad I pre-ordered Unity 5.

 

+1000 You Guys Rock!!

Heroes of Rune will be coming to WebGL!

 

hell yes, awesome news!

 

Will there be differences between the free and pro verions?

 

Oh no, I meant specific differences for that platform - for example nonsense like not being able to change the loading bar on the webplayer.

 

Thats what he probably meant as it goes like that in other platforms too, free vs pro. So free probably has some splash screen or load bar you cant change.

 

Yaaay! That's great news!