gman-toolkit-devel

[Gman-toolkit-devel] More Compile Errors

[AlistairL <Ali...@op...>]

After Recompiling,  I get the following Error.  

Making all in gman
make[1]: Entering directory `/spare/compile/gman/gman'
/bin/sh ../libtool --mode=link c++  -g -O2  -o gman  gman.o 
-L../libgman/.libs -lgman  -lstdc++ -lm -ldl -ltiff
 -lpng -ljpeg -lpthread
c++ -g -O2 -o .libs/gman gman.o  -L/spare/compile/gman/libgman/.libs 
/spare/compile/gman/libgman/.libs/.libs/li
bgman.so -lstdc++ -lm -ldl -ltiff -lpng /usr/lib/libjpeg.so -lpthread 
-Wl,--rpath -Wl,/usr/local/lib
c++: /spare/compile/gman/libgman/.libs/.libs/libgman.so: No such file or 
directory
                                       ^^^^^
Basicly the error is with the .libs directory being doubled up.  I have 
manualy worked around this one.  On futher investigation,  the error 
comes from the generated gman/gman/gman file.  I dont know how this file 
in created, or else i would fix it.

Alistair.

[Gman-toolkit-devel] Compile Error

[Alistair L. <al...@ne...>]

Making all in libgman
make[1]: Entering directory `/spare/compile/gman/libgman'
make[1]: *** No rule to make target `gmandefaults.cpp', needed by
`gmandefaults.
lo'.
make[1]: *** No rule to make target `gmanoctreeworldmanager.cpp', needed by
`gma
noctreeworldmanager.lo'.
make[1]: Target `all' not remade because of errors.
make[1]: Leaving directory `/spare/compile/gman/libgman'

Linux (Debian)
gcc version 2.95.4 20011002 (Debian prerelease)

I think this files are missing.  If I remove then from the Makefile,  I end
up with linker errors (unresolved Symbols).

Any other Ideas?

Al

[Gman-toolkit-devel] Shader

[Daniel B. <dac...@pi...>]

	Hi all, 

	Well it looks like gman development is slowing down. I sent in a
patch today that moves us closer to a raytracer, but it's still quite a
ways. I notice that the most important functionality that is still not
there is the shader language. I am assuming that this is because nobody
knows much about writting interpreters (the compiler should be fairly
straight forward, with lexx/bison). 
	So here are my thoughts. I know Pixar uses just in time
compilation, and can do nice things like use MMX/SSE to shade four pixels
at a time. I'd be happy if we could do 1. But it seems like we should
avoid writting a just in time compiler if we can, so what about using gcc?
my understanding is that all languages get compiled to an intermediate
format, which gets compiled/assembled in a machine specific way. Perhaps
we can take advantage of this second stage. The license would be only GPL,
not LGPL, but... at least it's something. Does anyone know anything about
this? Is it feasible? As another alternative we could use straight C code
as out "intermediate form". That would be slow as heck, but I think it
would be relatively fast to implement. 
	I would be much happier if we had a modular, but imperfect
solution that worked than a whole lot of framework and no pretty pictures.
			Daniel

[Gman-toolkit-devel] 0.1.3

[John C. <jo...@2a...>]

I have made the release.   This is only a bug fixing/update release,
but you may want to get if you are submitting code.

John

PS.   It is now required to have lex/yacc to build GMAN.   Hopefully,
if your on UNIX this will be no problem...
-- 
John Cairns
jo...@2a...

[Gman-toolkit-devel] release 1.3

[John C. <jo...@2a...>]

Does anyone object to my making a 0.1.3 release this week?

John
-- 
John Cairns
jo...@2a...

[Gman-toolkit-devel] Warnings

[Daniel B. <dac...@pi...>]

	Hi all,

	I spent a bit of time hacing on GMAN this weekend. One of the firs
things I noticed was that autoconf turns on optimizations and off warnings
by default. I turned warnings on and it was a little ugly. I sent John a
patch that fixed alot of them, but it's something to keep in mind. Before
I fixed them I spent an hour tracking down a bug caused by a function
having no return statement. 


		Daniel

[Gman-toolkit-devel] Architecture

[Daniel B. <dac...@pi...>]

	Hi all,

	I've been looking over the code strucutre so far and I have some
questions. 
	I just finished a course of computer graphics last
term and one of the assignments was to write a ray tracer; I figured I
would try to put in the basics of one into gman, since they aren't too
hard to get going. But I am confused as to how you see the different
renderers working and what exactly the inheritance levels represent.
	In the zbuffer code it iterates over each body, surface and face.
What do each of these correspond to? I am guessing that it is something
like
	body: compound object, eg. polymesh or nurbs mesh
	surface: single object eg. polygon or nurbs surface
	face: tesselated object faces eg. 200 triangles for a nurbs
surface

	Is this right at all? If so (or if not), where are objects
tessellated (or where WILL they be tesselated). What is the relationship
between GMANPrimites and GMANObjects/Bodies etc.? What is the purpose of
the getRSSphere etc. functions? How should they be called and from where?
Anything else you think I might need to know to take a crack at
raytracing?
	Also, two quick comments. The intersects function needs to return
a t value which is the distance of the intersection from the eye (divided
by ray length, usually). I know it's early for this, but I am not sure the
radiosity renderer should really be a renderer. I think it's more of a
prepass that calculates lighting (at verticies) that the real renderer
uses later. In other words, it can act as input for either a zbuffer,
raytracer or anything else. Could be wrong here, but... (besides, I think
it's kind of early to start worrying about that too much, on the other
hand, best to get your architecture down pat early).

	Thanks for the help and with a little luck I'll pay it back in
code shortly (no promises, another busy term ahead, as always :)



			Daniel

[Gman-toolkit-devel] 0.1.2 taken down

[John C. <jo...@2a...>]

I have taken down release 0.1.2 to prevent any copyright infringment
that my have been involved in coding the filters based on Pixar's
Spec.    

I will be making a release soon, probably 0.1.3, which does not have
this problem and has all of the latest code, including the new
renderer and shading language module loading system.

John
-- 
John Cairns
jo...@2a...

[Gman-toolkit-devel] You asked for it...

[John C. <jo...@2a...>]

I'm probably the least of the proponents of coding standardization
practices.   I believe it is my individuality as a coder that makes my
code worthwhile, and better than other's code.  Moreover, I feel that
people like to spend all their time planning, and never any time
doing.  If I had done that in Feb 1999 GMAN would not even exist
today.

Having said this, here are the coding guidelines that we, the
developers, have agreed upon.    

In short, if your going to submit code to the project, please read,
understand, and follow these coding practices.

As above, I usually disagree with coding standards, so I don't intend
to become the GMAN coding police.   Nobody else should either.   If
you submit code to the project, thanks for your efforts, we'll get
things working and readable in due course.  

John

-- 
John Cairns
jo...@2a...

[Gman-toolkit-devel] Loadable module support

[John C. <jo...@2a...>]

I added the loadable module support for loading dynamic shader objects
and dynamic rendering objects.      Have a look at GMANLoadable,
GMANLoadableRenderer, and the new directory structure under
'renderers'.   Each renderer now builds its own loadable shared
object. 

John
-- 
John Cairns
jo...@2a...

[Gman-toolkit-devel] get latest

[John C. <jo...@2a...>]

Hi All,

I updated many files as part of the release of our new coding
standard.   It would be wise to refresh your source tree at this
time. 

John
-- 
John Cairns
jo...@2a...