OGRE / Code:Blocks / MingGW / wxWidgets Installation ...

foreheadsobstinacyΛογισμικό & κατασκευή λογ/κού

15 Αυγ 2012 (πριν από 5 χρόνια και 1 μήνα)

539 εμφανίσεις

OGRE / Code:Blocks / MingGW / wxWidgets Installation Notes


Code:Blocks (CB) was originally downloaded for the purpose of enabling work with the 3D graphics API
OGRE.


But CB is a legitimate development environment in its own right, comparable in capabilit
y to NetBeans. As a
freeware API it has its share of ragged edges, but it is my hope that with a certain degree of "due diligence"
and a sufficient supply of Wint
-
O
-
Green lifesavers I can get it running.


A recent nightly build of CB, the only kind that wi
ll work is
here
.


The purpose of these notes is to document a competent installation.


For missing files, be sure to check “My Downloads” for possible packages.


MinGW is Minimalist GNU for

Windows, sidestepping Cygwin.


Currently MinGW 5.1.3 is installed on C:/MinGW


MingGW C++ Toolbox 3.4.5 w1 is also installed.


wxWidgets is used to build portable user interfaces


-----------------------------

Facts:


For Code:Blocks to start correctly t
he files minggwm10.dll must be copied into the CB directory.


For Code:Blocks to start correctly the files wxmsw26u_gcc_cb.dll must be copied into the CB directory.


The current Code:Blocks directory is

here
.


Shortcuts describing the Code:Blocks installation in the context of the OgreSDK are

here
.


Copies of these are currently
here
.


---------------------------


Also necessary for the support of the OgreSDK are the
Microsoft
Direct X SDK

which was downloaded and
installed per t
he shortcuts listed above to
here
.


A useful adjunct to Code:Blocks is wxWidgets which is installed
here
.
(Version 2.8.0)


-------------------


A set of useful tests


get the Ogre SDK demo suite running in a saved workspace.

get the wxWidgets example running

get an openGL example running

import a C++ project and get it running.


-----------------------


When c
opying the samples from the C:
\
OgreSDK directory to the kg3 directory

They will compile, but will not execute, complaining that they cannot find the file:


OIS_
d.dll when running the debug version and

OIS.dll when running the release version


Perhaps
the

problem is that Codeblocks does not like spaces in the longer kg3 pathname, as in “Documents
an Settings”. Perhaps quoting the path would work.


For now the workaround will be to just develop out of the install directory and address the porting issues
lat
er when a product exists.


I have joined the OGRE forums
here

and am waiting for my verification email.


I will post the error there.



To avoid getting stuck I
am reversing my backup strategy.


I will muck around with the C:
\
OgreSDK samples and leave the originals in the kg directory, backing up the
mucked around with versions, incrementally.



Here’s a big problem with the whole OGRE api.


It is a big pointer s
oup. All objects, and constructors and attribution takes place via the return of pointers to
the thing, and not the thing itself, producing all the uglies that I long ago did away with.


Choices.

Use Pointers.

Huge Rewrite.

Don’t use OGRE.



Let’s see how

easy it is to build an opengl application using wxWidgets.


After all, I am just showing graphs and they don’t need much of the full render glory, or do they??


To escalate well, especially directly to film, we do need the full render glory and this creat
es a problem in the
3 way choice vector above.


There is possibly another choice.


Build a minimalist interface layer that uses your style of programming at the high level and makes calls to
the ogre entry points in a disciplined way.



Start by taking an
example such as Demo_BSP and morphing it to display a graph of interest. Then
implement user interface features from other demo’s in an incremental way.



Ogre offers a set of basic and intermediate tutorials
here
.


They appear straightforward.


In the cookbook section at the last part of the tutorials, 3D line drawing is discussed.


It is incredibly ugly.


I am not sure Ogre is what I am looking for.


It would probably be worth the troubl
e to go through the tutorials and get to the place where a 3d lineset can
be drawn and viewed just to evaluate this.



In terms of GUI development that is cross platform, wxWidgets appears the best way to go after reviewing
FLTK, GKT+, QT4 (proprietary) Sm
artWin, and Win32 GUI.



In terms of 3D graphics alternatives:


GLFW is nice and simple. But includes no user interface (use wxWidgets???)


GLUT is out of date and poorly maintained.


Irrlicht is a strong alternative to OGRE. It has a built in GUI. It is m
ultiplatform.

Good license. Pointer intensive dialect, but less complex than OGRE and easier to develop entry points. The
GUI is weak and should probably be supplanted by wxWidgets to do sophisticated things.


It will save a great deal of time to use the I
rrlicht Code:Blocks tutorial
here
.


Lightfeather, a bit clunky but a possible alternative to OGRE.


All roads lead back. Use
Java3D
! It will work fine and includes advanced shading.


If you read the above link carefully, sound tools are also available.


So I think the strategy should be to finish the current incarnation in a web
-
based version.

You took care of
your son first. That wa
s your priority.



Monday, March 19, 2007


Downloaded and running each of the Java3D examples.

These notes show which capabilities in the examples are most useful for kg3.






Appearance
Test
:

The
vertex and node rendering

would be useful, as well as
tr
ansparency and background texture definition.

Scene resizes with window!





Applet3D
:

Running 3D in an applet, fairly trivial actually.





BackgroundGeometry
:

Background env map. Simple geometry. Primitive camera.




ConfigObjLoad
:

Reads a chunk

of pr
edefined geometry.
Better camera
control
.




DepthFuncTest
:

Apparent effort at
z buffer comparison
.

Undramatic and useless. Primitive GUI.




DistortGlyphTest
:

Good environment mapping. Ok Camera.

Good example of dynamic vertex updates.



Dot3Demo
:

Good

dynamic lighting example. Crude remote GUI.



EnvironmentMappingGLSL
:

Good environment mapping. Might be useful for shape
interpretation.




FourByFour
:

Drawing of nonzero measure points lines and primitives.




GearBox
:

Dynamic Animation of Apparent C
ause and Effect.

Useable camera.




ImageComponentByReferenceTest
:

Bliting by reference and copying.





InterleavedTest
:

Continuous Tone Fill
.







LOD
:

Nonfunctional attempt at Levels of Detail?




Morphing
:

Tweening a set of key frame mesh geometri
es.




MultiTextureTest
:

Different lights and textures on simple geometry.




ObjLoadGLSL

Load geometry and texture

Note the examples suffixed with CG seem nonfunctional on this wintel machine.




OrientedTest
:

Constrained camera motion
.




PhongShadin
gGLSL
:

Phong Shading Demo. Needs antialiasing!




PrintCanvas3D
:

Send a snapshot of geometry view to
printer
.

This is an important capability.




PureImmediate
:

Running in Immediate mode
.




QueryProperties
:

Query the local environment for graphics abil
ties
.




ShaderTestGLSL
:

Attach different shaders with different textures and
lighting models to the same geometry
.




SphereGLSL
:

Multiple shading simultaneously
.

Two lights and dynamic
environment model. See also SphereMotion




TextureByReference
:

Pe
rformance of several methods of texture mapping compared.
All were quite similar
.




TextureImage
:

Naïve texture mapping onto a cube
.




TickTockCollision
:

Collision detection. Bar turns Green
.




VertexAttrTestGLSL
:

Vertex attribute interpolation. Pret
ty basic
.




Development Notes Wednesday, March 21, 2007


Wanted to compare jikes execution times with jre byte code interpreter execution times.


Turns out the last update to jikes took place in 2004. So it is not particularly active or up to date.


Accor
ding to wikipedia, development on jikes ceased in 2006. My hope to compare compiled with
interpreted may not have been well
-
posed,

If jikes produced byte codes as output.


Thus the jikes experiment has been abandoned, and further Java development, if it oc
curs, will be using
standard java tools, like Netbeans, etc.



Another task was to make some development notes on cancer. I have done this outline as text.
Next step is
to illustrate it.



Create 3D pathway spreadsheet and database.

This activity seems per
ipheral. So illustrating the cancer
notes seems like top priority, absent a customer of interest.



Worked in Netbeans java3D. Added documentation to java library manager and project manager but it did
not seem to find it.


Added jVi key bindings and these

work well, with some refinements necessary for case sensitivity, etc
necessary later.


Want to build an analogy to the green graph paper, perhaps turning it into a Resource image rather than a
procedural background.

This way I could change the paper by j
ust making a new image, rather then by writing a program.


Remember Kernigan’s principle of just building the automaton. Keep as many things “resourced” as
possible.


I may start with a combination of pure immediate mode, since this should allow update to
knowledge maps,
and the AppearanceTest which displays lines and edges.


Basically getting my feet wet by rewriting these examples.


Later work could include translating Daniel Sleator’s link parser into java. And determining how to translate
sentence struc
ture into fact structure. That problem could be AI’ish.



Development Notes Thursday, March 22, 2007



I have figured out, to some extent what is bothering me about my development cycle.



It is too rigid and labor intensive to get small perturbations abo
ut some fixed design point, for example, 4x4
matrices, vectors, and problems that use them.



Before I expand let me explain my background intentions.



I have an application, KnowledgeGazer™ which lets one interact with knowledge maps. Knowledge maps
are
graphs of facts



Anyway, there is a test repertoire that to some small degree, freezes (unfortunate but accurate choice of
word) my software knowledge

such that I can verify that all my software functions correctly. Built into my system are example progra
ms of
how to instance the classes and call the methods. In one monolithic menu called “test”.



The trouble is that this is rigid. I cannot easily combine these things to make new things without asking
permission by writing class after class.



Digressing
again, my intention is to merge Java3D, with my graph algorithms. I also want to merge some
probability work I have been doing, provisionally under the charter of the test suite, that black cloth bag that
holds all the examples mentioned above. I have many

test programs and have taken the time to animate
their function on virtual ED engineering green graph paper, so they will make sense not only to me, but
eventually to other engineers and hopefully to a broader audience of students. Tall order.



It is in
the labor intensive nature of this merger that I am asking myself if there is not a better way.



One thing I have right now is a menu that runs each test category.



But this menu is built at compile time. Even if it could be read in dynamically it will s
till lack something.



That something is expressions.



Now I would like to program in the class primitives I have developed, without re
-
invoking all the complexity of
a language like Java.



When I think of lexical models that are natural, a functional pr
ogramming language seems quite natural. By
functional I mean algebraic, parenthetical and some other things that are immediately obvious to me when I
use a language but I don’t want to articulate now.



Certainly, XML, which has taken the world by storm, i
s pure despair as the basis for a functional
programming language. With the exception of raw PostScript I have never seen a less digestible or uglier
representation of knowledge for people to process. I suppose machines tolerate it, but the grammar is not
even LALR (k). It is scan forever and hope for termination.



What I want is, having gone to the trouble to build a class and do calculations with it, is to be able to invoke
instances of the class without programming in Java. The question is where to draw

the line. Throw out Java?
Reinvent awk, calc, and bc? Do everything as a Java instantiation? The programs are baroque and huge in
the number of unnecessary classes that foment out of a primordial muck of gratuituous complexity that is
unaccepatable. As I
speak I am downloading a 1 gigabyte biochem package written in Java. Thousands of
classes whose only job is to enable classes to talk to classes. Something is damn wrong.



Also I have a requirement, and that is to be able to see the results of what I do.
If I am working with vectors,
I want the ability to show the value of the vectors during the calculations so that I can understand them now,
and later, when I am on to other things. I want to build programs that can execute quietly and rapidly to
answer qu
estions I have, for example my current questions on probability. But then if I want to know what
the program is doing, I want the potential, if necessary to visualize every step, not merely to print out a
gigantic blob of text.



Further, as if that were n
ot enough, I want to benefit from the interactive duality. Specifically if I select, and
then move or place some graphic, such as an animation of a vector operation (ten are running right now in
the radar screen background to remind me what I want) I want
that placement to be remembered as part of
the original program. I then want to illustrate the other vector operations, which I have already done in a very
labor intensive manner, with similar ease. Changing fonts, making labels, and doing so without the
c
lunkiness (both speed wise and interaction wise) that plagues so many efforts of this kind perennially.



I can’t do what I want to do in Mathematica, in Excel, in Geometry Expressions, in Hyperception or in the
twenty or so other systems in which I am con
versant. I do not want to reinvent the wheel, but I am willing to
if necessary. I feel like a wheelwright, whittling the spokes for a Conestoga wagon in an age where more
should be possible.



Today I was helping a friend buy a bicycle. I picked up a front

wheel that cost $900. It was perfect, true, with
bearings that made no noise.



That’s the wheel I want to get around on.



What if one could have little chunks of code, written in a conventional language.


And what if there was a meta language for managi
ng the execution of these chunks of code?


Consider a small square on a screen. What if when you clicked it, that a piece of code executed. A small
one.


Consider the chunk of code for a menu.


What if the chunks could talk to each other, so that they cou
ld click each other as it were, as well as being
clicked on by the user.


I am wondering if that kind of paradigm would make any sense.



What if the user’s interaction with the screen can be translated to a set of equivalent language expressions.


These e
xpressions are then used to drive the operation of the program.


Further these language expressions are in the same language as the boxes that talk to each other.




Development Notes


Saturday March 24, 2007


Nice Doobie on the JSON.



Tonight I have dow
nloaded and tried:






Eclipse SDK




Flex 2




Adobe Apollo




FCC2 MLP




FDS2
-
win




FLXB




Netbeans6.0 (I usually use 5.5 but it doesn’t support meta object passing which addresses a problem I
mentioned)





I did find
this link

interesting however, since Matisse is actually useable.





Otherwise the rest is over a gigabyte of unperfected alpha bloat.



I’m back to an editor, a browser and
some script. The Java
-
Javascript connection is the one I will hammer
on as I recollect my wits from this massive, but necessary excursion.








-----
Original Message
-----

From:

brianbec@comcast.net [mailto:brianbec@comcast.net]

Sent:

Friday, March 23, 2
007 11:15 PM

To:

Van Warren

Subject:

Re: RIA and three symbols that changed the world.



"closure" is "composition"



f < x | g > y



is unixish for



let y = g(f(x))



which is functionish for



g o f : x
-
> y



which is categorish for ... well, i'm out
of notations :)



God help us, because someone sold the world on the idea that XML is better than < bra | ket

> text, but
JSON (JavaScript Object Notation) is

just all right with me, JSON is just all right, oh yeah.

S
-
expressions
didn't make it because the
y're too pure, and postscript / forth are just ok, too, but even more weird. But
JSON is gonna make it, oh yeah!



Making money from software is REALLY really hard, much harder than writing software, as OpenSource
proves. Microsoft made money from software
, by making a silk purse (Windows) out of a sow's ear (the IBM
PC / intel architecture). Google doesn't even try
--

they sell ads, giving away all their software, making life
particularly difficult for Microsoft. The future is unknown. Microsoft has not bu
dged in 8 years. Even Gates is
sick of Microsoft. It's the
http://en.wikipedia.org/wiki/Intertropical_Convergence_Zone

.



Proving yourself is REALLY REALLY hard. It's really hard
even if you're ON trial (Hi, there, OJ :), but if
you're not, it might as well be impossible.



I don't have answers. I'm lucky to have a job.



--------------

Original message
--------------


From: "Van Warren" <van@wdv.com>

I’ve spent the day looking a
t this. My current thinking is RIA


Rich Internet Application, but avoiding the
cobbled together, “mashup”. Mashups are for junkyards. I make precision stuff.



I like javascript, having developed in it before. However I also want the ability to select a
component and edit
its behavior on
-
the
-
fly. I also want to be able to have it interact with other components where the number of
interfaces is linear, rather than quadratic in the number of resulting interaction possibilities.



I want the user interaction

with a component to look like a component’s interaction with a component. This
extends closure to the graphical domain.



T, K & R gave us textual closure. Programs were text. They ate text. We fed them text. We fed them text
with our hands. They fed each

other text. They grew and grew and fed our eyes. Pure textual closure. Three
symbols changed the world, ‘<’, ‘>’ and ‘|’.

These three symbols could have actually been one symbol ‘|’.
There is nothing more beautiful than that.



Now we seek graphical clos
ure, web closure, select and edit closure, what? Web based applications
automatically solve the distribution problem if you are wanting to “give it away”. JavaScript forces us to “give
it away”. Php let’s us choose. You gave me two choice morsels of counse
l. 1) you don’t have to give it away.
2) you don’t have to prove yourself.



Unfortunately I spent my life doing both.



All the best,

-
Van


L. Van Warren

Warren Design Vision

wdv.
com

501.664.0411 land

501.231.5426 cell

501.588.1370 skype





-----
Original Message
-----

From:

brianbec@comcast.net [mailto:brianbec@comcast.net]

Sent:

Friday, March 23, 2007 12:14 PM

To:

Van Warren

Subject:

RE: some notes to myself



MUST SEE:
http://amaznode.fladdict.net/







--------------

Original message
--------------


From: "Van Warren" <van@wdv.com>

Thanks… especially for the cheerleader part.



All the best,

-
Van


L. Van Warren

Warren Design Vision

wdv.com

501.664.0411 land

501.231.5426 cell

501.588.1370 skype





-----
Original Message
-----

From:

brianbec@comcast.net [mailto:brianbec@comcast.net]

Sent:

Friday, March 23, 200
7 9:34 AM

To:

Van Warren

Subject:

Re: some notes to myself



I had to chuckle about "thousands of classes whose only job is to allow classes to talk to other classes."



Yup, it seems the world is 98% plumbing and only 2%... well, non
-
plumbing.



I'm remin
ded of Sim City, a lovely little game, where you're constantly running around fixing broken water
pipes and moving electric towers around and setting up money flows (yep, just like water and power) so the
people can keep to

the business of building their s
hiny city and so you can take all the credit for being
shinier than the guy in the next continent. And if you miss a sector, they die, move out, or riot, or throw you
out of office, or hang you.



ok, but to solve your problem...



I can solve it, really I

can, this time no fooling. No, really, I really can. This time it's for real. This isn't just the
20th date with the 20th cheeleader who turns out to be a drug fiend or steals your money while making out
with Raoul the gardener,

this is the real deal.



What you REALLY want is a language that can evaluate itself. That's so you can DYNAMICALLY, at run
-
time, try out new things, without having to bake them into emacs output first.



Ok, you can be forgiven for thinking

you wanted functional languages, but t
hat's only because of an
accident, and that accident is that, historically, functional languages always had self
-
evaluation. But they're
too hard to use because they're too pure or too ugly.



You gave yourself your own clue by noting that forth (PostScri
pt), awk, bc, perl, whatever have what you
need. They're not remotely functional, but they have self
-
evaluation, if only in service to a read
-
eval
-
print
-
loop.



Ok, I'll stop with the tease: JavaScript. It has eval and apply. It's Scheme, only useful, with
out the holiness.
For visualization, use Flash, and you don't have to purchase adobe's IDE. Google



AFLAX

PAPERVISION

SWFMILL

MTASC

KIRUPA



all free. You're in.


There is easy JavaScript <
--
> Java integration too, (Google it) so you won't lose all the wo
rk you did.


http://www.json.org/




The direction I am going to work towards now is working on the javascript
-
java connection. Using the
references above.


Perhaps eventually posting the kg2 version of the code on sou
rceforge.net



Dev Notes, Tuesday, March 27, 2007


I have downloaded the most recent version of processing. I am much happier with it. Simple. Extensible.
Small.



Dev Notes, Wednesday, March 28, 2007


I have done some

shuffling and built a makefile in:

/h
ome/van/public_html/KnowledgeMapping/KG/src/wdv


Typing make causes a new jarfile, compatible with processing to be built and copied to /tmp/wdv.jar.


This jar file can then be copied to the processing directory of interest for incremental execution.



Now

NetBeans and processing use the same version of the KG source code, so extensibility is mine!


-----------------


pick up on test1


make processing
-
0124/wdv/test1 relevant


fetch one example from kg3/j3d
-
examples and compile for processing.

gears might be

a good choice, or the sailboat for its geometry.


if it works, repeat for other examples.


diff KG/wdv/*.java code against processing
-
0124/wdv/wdv/*.java


use most recent version


condense and coalesce where reasonable


do this list out of order if it sui
ts you.


try to get the KG run demos working one at a time in processing,

then deploy as an applet and see if they work.



Big problem. Although it was possible to reference and run small trivial classes like Vec4 from processing
using a common wdv.jar fil
e, it was not possible to run a file that referenced the JAppletA type for various
obscure reasons. This effectively eliminates the possibility of using processing to preview incremental
graphics developments that are too awkward in NetBeans.


One alternat
ive would be to convert the JAppletA to a java main program, but this means losing many of the
JApplet GUI utilities.


Sigh, what to do.


Now searching 3D web apps in Google.












Thursday, March 29, 2007


Major progress. Used NetBeans 5.5 to create

a JDialog which contains the rudiments of a user interface. In
the first example, a menu and a slider were built into an applet in NetBeans. This was then compiled into a
jar file which was made available to a processing example. The result was that proce
ssing could see and fire
the dialog containing the graphical user interface. Issues


1) The Applet is currently in a project called MenuDealie. The name should be changed to
vanGUITestApplet and the jar issues taken care of.


2) The automatically generated

code is transplanted into class that is parallel to the Applet called vwMenu.
The name should be changed to vanGUI.


3) The file should automatically be copied into the processing directory.


4) When the code is transplanted one line must be commented out
, and one line added:




// setLayout (new java.awt.BorderLayout ());






jDialog1.setVisible(true)


each time the code is transplanted.


5) Make increasingly sophisticated GUI’s or create a baseline GUI that enables the vector and other test
runs in KG t
o be moved to processing.


6) Try if possible to keep the deployments dual, where there is a netbeans version and processing version
that share as much code as possible.





Friday, March, 30, 2007


Finally some definite progress.


Figured out how to make

create and use a common jar file.

Figured out how to use the NetBeans AWT Applet as a test rig for the GUI control panel.

Figured out how to define and use a control in the control panel to affect the actions in a processing window.

Figured out how to use

Matisse along with special code segments such that the code rip into its own class
has only one “special” line

that must be commented out by hand.

Played with various incarnations of the perspective camera model, and started to work on lighting, but need
some simplifying choices and framework for how to proceed.




Very happy with today's progress, because it represents not only progress on a
specific intention, but represents meta progress... an extensible approach
applicable to a wide variety of problem
s that accomplishes the following goals:




Browser agnostic, what we called "dual browser" at one time.




Platform agnostic, works on Linux, MacOS, and Windows.




Allows but does not require source code disclosure. This is a fault of
javascript approaches.




Compatible with existing and past e
fforts in 'C', C++ and Java.




Programs may be 3
-
D, OpenGL and exploit high performance graphics.




Compatible with large pools of existing source code.




Fully interactive (eventually).




Supports rapid prototyping.



I was going to make a simple gui
for each example but there are issues as to
how to span the range of possibilities with the most common GUI possible. One
problem is lighting. There can be multiple lights. A stage is typically set
with multiple lights. There can be multiple material color
s. I had wanted to
keep things simple and just provide a light, like the sun and go with that.
There are two possible choices.


Make a table of lights and allow each instance to be turned on and off as part
of a “move”.

Make a table of objects and material
s ditto.

Make a table of cameras and viewpoints.


The tables could be saved as a file and read back in.


An alternative would be to allow one light, one object and one camera.


The bootstrap method is to start with one light, one object and one camera, and

then handle the multiple instance problem separately with a table driven
approach.



My goal is to span the space between enhancing the current examples, my own test routine examples, the
knowledge mapping needs with 3D graphs, the probability results wit
h charts and graphs and so forth.


To do this I need to:


Surv
ey the processing examples here and sketch a GUI for each.

Survey my test run examples here and suggest their factoring, for instance background html and little
applets.

Then sketch the GUI or e
ach.

Survey my knowledge mapping menu layout.

Survey the design for pre
senting the probability results and sketch a GUI for each.


The question is, what are the minimal GUI elements that provide the greatest capability for programming
effort expended.


I a
lso want to be able to import geometry created in another program, and create functional relationships
between chunks of geometry. For example, the animation of the iris and zoom of a camera. I would just like
to show the turning to the turret of the camer
a, and the change that results in the field of view. I would like to
be able to store state waypoints for the purposes of creating a move.


In a camera move, a given camera has a start state, an end state and k


2 intermediate states spanning
some time fr
ame = end time


start time. During the move the camera state vector is splined smoothly. A
move can be recorded in a camera script file for later playback. The camera move is independent of the
changes on the stage and the changes in lighting, although th
e director may choose to have them
correspond for artistic reasons. They are just not forcibly correlated, or overconstrained.


In a light move, a given light has a start state, an end state, and k


2 intermediate states spanning some
time frame =
end tim
e


start time. During the move the light state vector is splined smoothly. A move can be
recorded in a light script file for later playback. The light move is independent of the changes on the stage
and the changes in the camera, just as in the camera cas
e above.


The question comes up as to whether the camera and the light moves are forced to share common end
points. I don’t think they should be required to. The simulation simply advances putting whatever cameras or
lights should be in their states at the

correct interpolated times.


In an object move, the object simply undergoes its simulation transformations as defined by the procedural
or data model.


I want it to be easy to combine procedural models that model function, with geometric models that model

form and surface characteristics, with lighting models that illuminate and camera models that record.


The procedural models + the geometric models are called the simulation model.


So the simulation model is developed as are the lighting and camera model
s. The scripts are saved and run.


The results can be presented as applets, as applications using processing as the display vehicle.


Ultimately they can be recorded on other media if necessary.



Monday, April 02, 2007


Excellent progress today, haven’t f
elt this good in a year, development
-
wise. Not since Geometry
Expressions anyway.


Got a first applet done, called it NewPerspective. Uses a gui built in Netbeans 5.5 using Matisse. I now have
a functional development cycle.


There was a problem packing up

the applet and I have reported the bug
here
.


I will keep developing other stuff until it is fixed and then just deploy everything.




I am happy because now I do not have to give my sou
rce code away unless I want to, unlike javascript.


I can rapidly check the tools I build in netbeans, and then fit them into the processing framework.



Tuesday, April 3, 2007


Having completed the task of taking a processing example and build a simple us
er interface for it using
Matisse and NetBeans, I would now like to go the other way and implement my knowledge mapping
program using a similar technique.


I want to bootstrap my way there, by transferring the small test cases, and then ending with the kg
application. I would also like to illustrate some of my probability examples as I gain expertise in designing
lightweight user interfaces.


The trick is to start simple! I also need to get the applet bug solved, but in the interim, let’s see how the
applic
ation model works.


Application model works great and produces a salable little gadget. Me like!


It also creates apps for three platforms simultaneously. How cool is that?!


Was able to get ED paper working and sketch working relatively quickly. This was
very satisfying.






The evolving rules are that the graphics stays in processing’s purvue while logic and user interface
(including ui graphics) is in the netbeans purvue, with some flexibility back and forth for prototyping. Very
fast to code stuff up

and see if it works.



Wednesday, April 4, 2007


Principal progress today was factoring the code into a consistent directory structure




and adding some options to Pgui/NewPerspective specifically stroke weight and color.





Friday, April 6, 2007


Tod
ay was a mixed back. Succeeded in getting the whole wdv library available to processing without errors.
So I could adapt the various display routines to processing.


But I am having a problem getting ED paper to display in processing. There may be a workar
ound to this,
and if so, it is worth another day to get it.


Another alternative to consider would be to prototype code in processing, using available wdv library
support, but then codify the results into netbeans.


This creates a one dimensional workflow
from processing to netbeans. But allows netbeans support. The
problem is will the 3D processing stuff migrate properly into the netbeans environment? Is there a jar file?


I just need the interpretive power of processing for the complexity of graphics deve
lopment. Then it can get
fro
zen in netbeans after it works.



Saturday, April 7, 2007


After going back and forth I was forced to re
-
implement EDpaper in processing, rather than as a separate
class in a jar file.


The current rule is that if a file does gr
aphics, it has to live in processing. If it does pure computation or
implements a user interface, it can live in a jar file.


A compromise position would be to run the EDPaper in a separate subframe, like I do the user interface.
Have to look at that!



Monday, April 16, 2007


I broke everything today by upgrading to Java 6 but it turns out that wasn’t the source of the breakage.


The problem was that the system didn’t have the right layout program swing
-
layout
-
1.0.jar or somesuch that
comes with Netbean
s.


But that wasn’t the problem either. The problem was that when I deleted border layout, it used a freeform
graph layout and there was a hook into the applet code such that the only fix was to enable PGUIa/pgui.java
and PGUIb/pgui.java to extend applet.

This picked up the layout hooks and things started to compile again.


Now KG is even working in PBUIb, at least vmisc is showing up in a frame. The problem is that KG itself is
broken. See if this can be fixed by resorting to a back’ed up applet. EDpaper
has been modified extensively
and I don’t want to lose those changes.


Also I want to use the more recent version of VMisc that has entab copied into EDpaper, and I want to move
the test of hashing into VMisc itself rather than having it as an external te
st protocol.






Wednesday, April 18, 2007


When trying to get tools to be the correct size, and wondering where in the inheritance tree things are set,
the answer is, “midway”.


Not what one would expect.




In this example it is the jtoolBar that get
s setBound() set, not at the
jDialogToolBar

level.


Today I reached the critical threshold of complexity.


This is, everytime I tried to fix or debug anything, I ended up breaking something else that was working.


So no progress was possible.


For the firs
t time, I know what the problem with Java is.


The problem with Java and NetBeans are that there are many choices, too many ways of almost doing the
same thing, and these choices conflict semantically with each other.


I am certainly not the only person ex
periencing this, but I must change approaches to something that is
simpler, more extensible, and certainly more maintainable.


I am going to look at browser borne applications and see if I can put together some 3D support in Firefox.