Clarifications about Unity 5

draft

There is some misunderstandings about Unity 5 out there, so here are the facts as I know them:

1. There are three scripting languages, but one of them is not Javascript. There is a “javascript-like” language but it is not Javascript.

2. It is said that Unity has its own IDE, but it seems to use MS Visual Studio for C#

3. C# seems to be standard but of course there is no .NET, there is an equivalent to it however.

4. I was advised not to try and read data files from Unity but in fact it works very well.

5. Unity does seem to support GLSL shaders for standalone systems (e.g. desktop Mac, Windows, etc) Documentation for this can be found here.

https://en.wikibooks.org/wiki/GLSL_Programming/Unity

I have mixed feelings about this.

Amazing Simulation of 1970s Graphics in WebGL

Its the mid 1970s all over again.

I actually have written my first WebGL application to display a .obj file.

First you have to convert the .obj to a ".json" file, and then type in its name to some code.  But this process which might seem awkward and stupid, is actually all the more authentic.  This makes the application feel even more 1970s with a retro user interface.

The image is of my test object, a viewpoint .obj of a playing card.   By being completely flat, believe it or not, I can test certain things in my code that was useful.  Yes I know, its not the most compelling 3D object you have ever seen, and you would not even guess that the object is lit, but it is.

So far I have only found one incompatibility between Firefox and Chrome, that being the ability to see the "." as in "period" in a javascript program.   Firefox can, Chrome can not.

The great advantage in having all this in HTML is that it provides all sorts of tools for layout, fonts, scrolling and so forth.  Thus the "program log" window on the far left scrolls which was trivial to implement.

Wow!  Thats exciting, isnt it !

Technical Notes

Ok, so the status display is wrong.  In fact this is the line segments of the very flat 3D object that you are seeing.   The display does not become correct until the user rotates the object and from that point forward it is correct.   Fixed in the next release.

More Balanced Commentary on WebGL

No matter how frustrating the process, after a while one learns what can be done with a system and how to get around whatever it is you need to get around.   In this case the surprise was that I simply did not realize to what extent programming WebGL meant actually also working with both Html and the DOM, even though in retrospect it is obvious, and even more than that, this is what you would want.

You want it to be involved with HTML and the DOM or how could it all be integrated into the browser otherwise.

So its all good.  

There are some mysteries in the direction that OpenGL ES 2.0 has taken.   These mysteries can no doubt be explained by the designers, but they haven't done so, not that I have been able to find.  The specific questions involve the extreme position they seem to have taken to remove many things that people who program graphics use.   Its not so hard to implement your own versions of these things, e.g. a perspective matrix, a uniform variable to put it in, etc.   But it does make one wonder why they took it out to begin with?   Maybe they are just trying to be minimal?   That could be good.  But it is a little puzzling when you know the earlier versions of OpenGL and just leap into this and can not find things you expect.

Same question about perspective matrices also applies to lights.

And they seem to have some major browser architecture issue which I will call "the problem of the lost context".   Its annoying but can be managed.

On the positive side, by being so integrated with Html and DOM it is trivial to do multiple window layout and such things as scrolling text windows that might otherwise be difficult.

So far it seems to work and browser incompatibilities between Firefox and Chrome have been minimal.

Real Time Programmable Shaders and Me

[or is it "... and I" ?]

As part of my Solari Sign simulation, I am working through more of the learning curve on Open GL shader language, e.g. GLSL or programmable shaders.

It is pretty cool but it sure is awkward.

There is a list of things you have to get through that are arcane in the extreme before you can do basic programmable shaders: compiling, linking and running shaders, creating and setting uniform variables, creating and using texture maps, figuring out the relationship between traditional Open GL and the new programmable shader paradigm, and so forth. As with so many things in Open GL, going from the documentation to real applications is not well documented or self-explantory. The list goes on and on, and when you need to add a new feature, you have to be prepared to dive into the bits for days before you emerge.

But once you build up an infrastructure to make these things manageable, then it is a lot like writing shaders in Renderman circa 1988, but in real time.

And real time is fun.

For example, out of frustration with an object that was relentlessly invisible no matter what I did, I mapped a texture map variable I had been calculating left over from a previous test. To my amazement, I picked up the texture map from the last digit of a digital clock I had running on the display. Only in this case it was mapped on an object that filled the screen, and it was changing every second.

Its soft because the preloaded texture maps are 128x128 but that could be easily fixed. 

Anyway, I think NVIDIA or someone should do the following:

1. Document the relationship between Open GL and GLSL with modern examples.

2. Write and document a toolkit, maybe libglsl, that lets one do basic GLSL functionality at a slightly higher level.  If no one else has done it, I may do it.

         Such things as: read shaders from disk and compile into a program, defining and setting

         uniform variables, loading and enabling texture maps, etc.

3. Create a good implementation of noise, classic or simplex, and make it available.

        There is an implementation of noise that looks very good online, but it is 10 pages of

        code and its days of work to transfer it to your program. That is less work than it would

        be if you had to write it from scratch.

As for using real time graphics for work directly in motion picture filmmaking, in other words, as final footage, that will only work for certain kinds of graphics.  For visual effects and most final animation such things as advanced filtering, motion blur and global illumination is either required or highly desirable.

For a very low budget film of course, anything is possible.