Monday, December 27, 2010

Jerusem Circles And Picking

Merry Christmas and Happy New Year.

I'm working on the Jerusem Circles. I'm using Blender to create them and when they're done, I'll put them in the Virtual Urantia System as both a separate scene and on the Jerusem sphere itself. Finally, a bit more content from the book. Programming takes so much time that content becomes a low priority. Can't wait till Native Client is released in the first quarter. It's got me really excited. The idea that when I make a change or add content to the system, it'll be immediately seen around the world sends shivers of excitement through my bones. I hope it is everything that Google says it will be.

A little more on the circles. The circles are interesting. The centers have different structures. One is a monolithic, transparent crystal that is 50 miles in diameter and serves as the administrative center of the system. Another has 619 temples acting as a working model for Edentia. It's forty miles in diameter and is an actual reproduction of Edentia true to the original in every detail. Wow! Splendor comes to mind.

I believe the circles and triangles and gardens of Jerusem will probably be second in detail to Urantia itself. Urantia has this broad history running through it's evolution and then it's detailed history right up to modern times. I haven't decided how to approach changing the times on screen yet. Maybe a double clock floating in midair to the right of the planet. One showing large scales to be selected and the second being a finer split of time. When the hands are changed you see changes taking place on the planet.

I've figured out how I will program the flowing of the races across the planet. Imagine seeing the racial colors blend and seeing the colors float across continents while seeing the clock move it's hands. I'll use a morph shader for that one. Everything is ready in the desktop world, but alas, not in the world of the Internet, which I realize is the only world that is going to matter. One must be persistent and tackle the grunt work if beauty is to be expressed.

With that thought, picking has become quite a problem. Qt3D may have a real problem with picking, picking once again, is that act of selecting a hand on the time clock of the Earth I was mentioning and then moving the hands forward or backward. There's a problem when having large amounts of objects in a scene where I use the same geometry across different objects, like spheres maybe, where it picks the original geometry only. That won't work. Hopefully, I can be ready by the start of the New Year to explain to the 3d team what is taking place within their system that is causing this picking problem.Or maybe I'm doing something wrong. The brain, though, is ready to handle all the tasks of passing the clock's hand changes to the system. That works and has worked for a long time now. The brain that drives the Virtual Urantia system works well, it runs Power Plants and all the features that are needed to create the trip to Paradise are there in the desktop world but not in the Internet world. Once I'm done getting this OpenGL ES2 and Internet jump, content will once again take first priority. Nothing but fun here.

Monday, December 20, 2010

Jerusem circles and Native client

Good news Native Client will release at the beginning of the year in Q1. It'll be part of Chrome 10's release. Hopefully Qt will support it soon after. Also working on getting the Jerusem circles done before I forget what I'm doing all this for.So this is the story. Get Qt3d working so that I can place 3d in the web browser, get the effects system transferred to it also, then get it working on Native Client which runs the program directly from a browser without installation and then create the effects for the the trip to Paradise. I'm skipping a lot of steps but it's the general direction that matters here.

Im getting closer every day.

Friday, December 17, 2010

This picking thing is taking a while

Since I can't seem to get Qt3d's system working on picking, I'll add the code into a sample cube scene program. If it doesn't work there, I'll add it to Qt3D's bug list and send them the program. The're really a responsive group.

Also, on the embedded side, the instrumentation computer from Wago (their automation systems are worldwide) won't support 3D accelerated graphics. It makes me wonder how many TV's will support the running of 3D programs from the Internet. Since some of them use the 3D glasses, I should have a lot of success with the new TV's.

Here's the correspondence I sent to Wago, leaving out names.


Using the Mesa 3D package, I can still use the IPC. It  wouldn't have any acceleration or shader effects, so I would lower the 3D frame rate to a crawl but they can still see their stuff in 3d. I'm hoping that your engineers will use the OMAP 4 TI CPU. A local Panda Board, which has a twin ARM based solution with a 3d graphics accelerator, connected to your local ethernet based coupler will give me 3d accelerated graphics. At 175.00 plus the cost of a 5 volt power supply and cables for the touch screen will work.

Thanks for the effort

Pierre Chicoine

Tuesday, December 14, 2010

A picking we will go, a picking we will go, hi ho the merryo

Figured out the picking scene thingimabob. Yes it's true, an extra scene handler is needed to handle picking and now that I understand what they want, it's all mechanical now. I know, I know, you're saying to yourself right now.. Pierre, tell me more, I'm just so fascinated with this picking stuff, I'm just biting at the bit to know. Well I wont leave you hanging. QGLAbstractScene is needed to do picking. Who would have thought.

Is this the way to Paradise?

Thursday, December 9, 2010

Back To The Future with Qt3D

Had a lot of help from the Qt Qt3d team and got some speed back on large scene viewing. Large scene, that's where there are a lot of objects (meshes) in the scene. The Ubook Paradise trip has a lot of objects so it has to work with enough speed to spare so that the 2d menu and combo box stuff respond without crawling. My test platform has 937 objects and before the fix, it took 10 seconds just to turn the scene.

It's a breath of fresh air and I'm back on the road to getting it done in 2011. Picking (object selection) is up again.

On another note. Why use my system to create the trip to Paradise? After all, there are a lot of systems that can do a far better job of creating the trip to Paradise, Blender, for one. The answer is this: I created the system with the capability to manipulate the environment such that when you click on Jerusem, you get information from within the book that shows Jerusem stuff. That kind of manipulability relating directly to the Ubook cant be duplicated with any of those fantastic packages. They are built to do animation for movies and the like and not to be an interactive educational system with direct database connections to the book. Also, from what I've seen, they cannot animate from events such as mouse clicks. Further, if they we're capable, they can't output that capability to the Internet. Also when on the Internet, they can't share creative experiences like interactive creation of differing scenes over the Internet.

There are, literally, hundreds of reasons why I chose to use my system. The primary being is that I could. I dream of a day when thousands of people create Ubook stuff in collaboration.. Before that can happen, I need Qt on Native Client. 2011, I hope.

I feel the drive inside pulling me towards that dream, a kind of unconscious attraction. Where it comes from, I don't know. If it doesn't happen, it won't be because I didn't try, It'll be because I have lost my ability to program. Even if all I could use is my nose, that's what I would continue to enter programming text with.

Saturday, December 4, 2010

Up And Running on the N900

Did my compile for the N900, it worked. The N900 is Nokia's Linux phone based on the OMAP Arm embedded processor. I have a ways to go and a lot of programming to get the basic primitives back up and running on the Omap Arm processor. The program runs but no 3D. Had some two months ago, so I have some backtracking to do to get cubes back up on the system. First cubes and rectangles, then lines, then cylinders, then spheres, then complex objects and a few other dynamically created shapes and I'm home free. Maybe by 2011, I'll have 3D up and running on embedded platforms. Then when Native Client releases and is made to run on Qt, I'll be running everywhere and I can concentrate on getting content and pretty scenes up for the book.

When all that's done, I'll be licensing the system. Can't wait to get there.

Thursday, December 2, 2010

Picking Objects in an OpenGL scene

Ok this one's a bit technical.

Picking is the ability to select an object with a mouse or on the screen. Up to now, the picking system worked flawlessly but picking now has to be upgraded from OpenGL to OpenGL ES2 if I'm to run on the Internet using Native Client. In OpenGL, picking was handled automatically with a simple function that OpenGL use to show me index number of the object but now it's not there anymore. So here is how I'm going to do it. Instead of figuring out the an imaginary ray in 3d space that traverses all the objects under the cursor, a complicated scheme, I'll do with coloring the objects. It's a lot easier to program. Every second of time, I recreate every object in the scene more than 30 times a second, that's a lot of stuff happening really fast. Since I tell the system what color each object is going to be anyway, then on the frame that is sent when the user clicks, I will color each object with a unique color. Then after the scene is drawn, I'll get a picture from the graphics card of the scene, then look at the X and Y position of the dot under the click of the mouse and using a pre-created list matching color to object, I'll know what object has been selected by using the color as the index into the list. Voila object picking. Well, that's the theoretical side anyway, now I have to figure out the code that makes it work.

You know, it's almost like I know what I'm doing.

Tuesday, November 30, 2010

Qt3d not ready

Wow. It took a couple of months of work to figure out that I can't use Qt3D, at least, not yet. As it stands, it's just too slow when used in conjunction with my system. When they've cleared up a few problems, especially the way they apply objects, I'll engage the code and try again.That was a very difficult decision to make. Upgrading to OpenGL ES2 is even more difficult using my old approach but I have no choice as of today.

I cleared up a few problems with some Qt upgrades. No objects could be created from menu and key presses are ignored, don't know why, somewhere along the line, Qt changed the way they do things and it's up to me to keep up with those changes. 3d development is gruesome but it's the holy grail.

Anyway, no matter how long it takes, I plan on having a system that deals with this book the way it deserves to be dealt with. Period.....

If I had unlimited funds, those funds would go into the creation of 3d views of the Urantia Book's concepts. Using the system, I plan on licensing it and using that to fund hiring people to create objects like the Jerusem circles. These objects can then be used, painted and manipulated by the system.

Onward and upward

Thursday, November 25, 2010

Fixed 3ds object imports on Linux-like operating systems

Wow. Thought my object import system was dead. I forgot Linux cares about upper/lowercase. Works again. God I love Linux, its just so powerful. Apple, though, is really an awesome platform to test the underlying BSD platform that the Apple runs on.

Sunday, November 21, 2010

Upgrade Failure on N900

Got impatient and tried getting an update on the embedded platform.

Using Qt3d and the Nokia SDK, I am unable to get a working copy of the Virtual Urantia book on the N900 cell phone. I'll be waiting till the Nokia SDK releases with version 4.7 or 4.8. For now, it's still working with version 4.6 which unfortunately doesn't support the new Qt3D SDK.I could try to compile the 4.7 Qt source with the Maemo (the operating system for the N900) toolkit but I have better things to do than to get impatient and waste time when I'll be able to do it with the next version of Nokia's SDK for devices.

It would be nice as I can show off my progress to Marlene and also prove to myself that what I'm doing will work with the OpenGL ES2 hardware.

Oh well. I have other things to do. Back to Object Picking on Qt3d.

Wednesday, November 17, 2010

Large Scene Efficiency fix

Finally, I have the embedded platform's large scene efficiency working. The whole system won't come down to a crawl on a cell phone. It's time to work on the picking part of the platform. That is, selecting an object in a scene. This way, I bring up pertinent information about the object, say Jerusem, for instance. I'm still waiting for Qt's upgrade to Pepper2 on Native Client. I think I'm over the hump of getting this to work on OpenGL ES2.

Next comes getting the effects system I just completed last month to take the jump into OpenGL ES2.

Monday, November 15, 2010

Native Client

Both Saturday and Sunday I spent trying to compile Native Client and Qt. No luck, not really a lost weekend as I'm relearning the ins and outs of Linux again. I'm done with Windows, just too many security risks, that is, for development. I will, though, recompile (recreate) the program on it at intermittent intervals. Anyway, without Qt, I have no Native Client and with no Native Client, no Internet.

Received an email back from Morten Sorvig at Nokia. He's explained that he stopped working on Qt compiling in Native Client until they release Pepper 2. This is more of the real thing as Pepper 1 was the release that didn't support all the sandboxed protection on the Net. They're a month late, so any day now.  

A lot of people think that this computer business is changing too quickly. From my vantage point, it's like Molasses. It's worth the wait, though.

Back to working with QT3D and the conversion to OpenGL ES2. I'll put together the scenarios and functions to show that I can't, as yet, get it working with large scenes or they haven't handled it yet. Both Power Plant and Virtual Urantia need large scene efficiency and I haven't found the secret that will allow Qt3D to be efficient with large scenes yet.

I'm doing double duty here. I'm working on my own version of converting to OpenGL ES2 without QT3D for now. I can't be sure that their system will be ready or capable as yet to go full speed. The worst thing that can happen to a programmer is to up against a wall without a way out.





Friday, November 12, 2010

Qt3D and the Net Continued

Here is where Qt3D comes in. Qt3D is a research arm of Nokia's Qt software development kit (SDK). Jumping to a platform such as OpenGL ES2 when you're stuff is written in OpenGL is not a trivial change. The mathematics of 3d is very complex.

(Skip this paragraph if math is not your friend)
Take a simple cube for example, every corner of a cube has to be entered into an a variable array with 3 floating point numbers. Since there are 8 corners, this adds up to 8 * 3 or 24 floating point entries. Then in a separate array, a normal entry has to be made for each corner which tells the corner where to reflect light from. Then every face corner has to entered into an index that describes each face. That's 4 entries for each face. Since there are 6 faces, that's 6 * 4 = 24 entries. That's a grand total of 24 corners (vertices) + 24 face descriptions + 8 normals or 56 entries in 3 separate variable entries.

Now that I've described a cube, imagine the resurrection halls of Mansonia. Thank God I have standardized programs that can create these objects for me. For that I use  programs that create the 3d entity. I still have to deal with manipulating the arrays and delivering them to the graphics engine. I use Blender for that. It's open sourced, so it's free and is capable of creating all the 3d content I need to get the Urantia Book in 3d.

Ok. This is where Qt3d comes in. It makes it easy for me to take these arrays and properly present the objects with the right mathematics to position, rotate and resize them in the scenes that are created to present the information to the user.

Using Qt3d and Qt, I am now capable of presenting 3d content to the graphics card in an organized fashion using OpenGL ES2.

The next step is getting it to function on the Internet. Nokia's Qt SDK has an arm that has just released a project called Lighthouse which, hopefully, simplifies getting the system to work on differing types of computers. It has a branch that
takes my code and resets (recompiles) it to work on Native Client. Native Client, as I alluded to earlier, allows C++ programs like mine to work on then Internet.

A little bit on Native Client. Using the Qt's Lighthouse project, I can place my system through Native Client on a normal browser. The code is sandboxed, that is, protected from damaging the local computer and then it is presented to the user as if it had been installed. Google has a front end using Native Client's way of compiling the code (making my code usable by a computer), that first, makes sure that some methods of using the local computer aren't entered into the program and then they insure this when the user accesses the code by visiting the page on the Internet.

At that point the program downloads and is tested for compliance so that no program is capable of damaging the local computer. I think that Google has breached the new way of using the Internet. A real stroke of genius for Google and the power that will be placed on the Internet. The first time you download the code, it takes a bit of time and from then on it only downloads the changes. This way, when I upgrade, I won't beset the users with long waits. I've asked the programmers to add a wait progress icon to help with long waits. I'll be entering it in their bug and suggestion system today.

My hope is that Google succeeds with this platform. It represents the largest change to the Internet since it was born and will bring power between disparate systems. I create my own hardware, that is, build my own circuit boards and one thing that doesn't escape me is that the entire breath of hardware makers and controllers use C and C++ for control of their hardware. It is by far the best way to manipulate a CPU or GPU directly (Central Processing Unit and Graphics Processing Unit). So it goes to follow that most of these people will be able to control their stuff over the Internet if they are given the chance and that is where Native Client comes in. That is not the end of the story. All the major software is generally written in native code like C++ and now with Java. JavaScript is different, it is what is used on the Net. They will also give Cobol and Fortran the capability to present their programs also.

So, programs like Adobe Photoshop (if they take advantage of it), will be able to run from any computer on the net. That includes the new TV you're going to buy.

So a new age is born and I've waited long enough to get on the Net. Two days ago, I started playing with getting up and running on Native Client. Since the system is not completely ready for OpenGL ES2, 3d will have to wait till that's complete using Qt3D. In the meantime, I have the searching and indexing system running on the Urantia Book and it is capable of looking up things pretty quickly and in many different ways. Working directly with the Urantia book, I am capable of doing a lot of really interesting things with the book.  So that's what I'm putting up on the Internet first.



I've read some of the dissenting voices coming from the industry as far as Native Client is concerned. For instance, both Firefox and Opera say it's dangerous and they seem to be resisting the change. First comes rejection, then apathy, then acceptance. I guess it's the story of humanity. I've looked at their concerns with security and there is no doubt in my mind that ActiveX on Internet Explorer, Firefox's NSAPI, and the like are far more dangerous and have been creating the enormous virus and trojan problem we're having. I don't know anyone who hasn't been affected by these. Native Client will pretty much eliminate all of that. I use Kubuntu Linux now so I'm not plagued with any of these problems but everyone I know using Windows has been attacked. For now, Google's Chrome and Firefox are the only two working as yet. Chrome mainly. It's a good browser and will probably gain a strong following until Firefox and Opera have decided to use the Native Client code instead of Google forcing Native Client through NSAPI and the like.

Anyway, I am fully dedicated to bringing the Virtual Urantia platform and it's evolution to the Web, that is, as long as I'm mentally capable.

From now on, I'll be posting my efforts here, probably on a daily basis.

You can type in "Pierre Chicoine" Qt3D with the quotes around my name or "Pierre Chicoine" "Native Client" or PierreChicoine Qt3d or Pierre Chicoine Virtual Urantia to see some of my 3d exploits.

Qt3D and the Net.

This my first blog entry, so it's detailed.

There are two main steps in getting the Virtual Urantia book online. The first is getting the 3d engine side of the system into a format that will be recognized by graphics cards on differing computer architectures on the Net.  This is where I use OpenGL ES2.  In 2001, I switched from Microsoft MFC to Qt from Trolltech. I began writing this system with Microsoft MFC in 1996.  Qt being cross platformed and Microsoft being locked to Windows only. The problem right now is that I am using OpenGL and not it's successors OpenGL ES2 and OpenGL 4. OpenGL ES2 works across all desktops and embedded platforms. Examples of embedded embedded platforms are your cell phone, your higher end TV, your new notebook, even your newer remotes. I'm writing this entry from my cell phone as I am still in bed.

The second is getting it working in a browser. I've learned that very few people are willing to download and install a program into their computer. It has to be easy and painless. Give them a web address and that's the depth of the involvement. That's not an easy thing to accomplish. I write in C++. I can't imagine using anything else at this stage. When I first started tackling this problem, I looked at ways of delivering 3d content on the Web. X3d was one of my attempts. After a month of work, I decided it would'nt work. I waited several months while creating the effects system in OpenGL ES2 and the answer came with Google's Native Client. Here I see a a way to get my system on the web without a complete rewrite of 10 million typed characters of code. That's more characters than the Urantia Book itself. Using Native Client, I'm capable of writing the whole thing in C++. Whew!

So much for now.