plib-users

Re: [Plib-users] SSG loading lights

[Steve B. <sjb...@ai...>]

Dan Gelb wrote:
> 
> The different ssg loaders don't seem to load lights for any of
> the formats.  Is there any chance of light loading being added
> to any of the loaders?  I'm using the 3ds and ASE loaders currently.
> 
> I'm guessing that no game creators store lights in the model files.
> It doesn't look too hard to add though.  Dave mentioned cleaning up
> the loaders and having them use ssgParser.  I would vote for having
> light loading added if possible.

If we do this, it needs to be something that the application can
turn on and off (and it should be off by default).

SSG only supports the standard set of 8 OpenGL lights - and how those
are allocated between the modelled lights and the one(s) that the
game sets up is going to be a hard call.

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

RE: [Plib-users] SSG loading lights

[Dave M. <Dav...@dy...>]

Dan wrote:
> The different ssg loaders don't seem to load lights for any of
> the formats.  Is there any chance of light loading being added
> to any of the loaders?  I'm using the 3ds and ASE loaders currently.
> 
ASE files contain lights (if you check the box for them in 3dsmax).  there
is lots of info there.  for example,

*LIGHTOBJECT {
	*NODE_NAME "Spot01"
	*LIGHT_TYPE Target
	*NODE_TM {
		*NODE_NAME "Spot01"
		*INHERIT_POS 0 0 0
		*INHERIT_ROT 0 0 0
		*INHERIT_SCL 1 1 1
		*TM_ROW0 0.0000	1.0000	0.0000
		*TM_ROW1 -0.5505	0.0000	0.8349
		*TM_ROW2 0.8349	-0.0000	0.5505
		*TM_ROW3 611.2228	-0.0000	413.9070
		*TM_POS 611.2228	-0.0000	413.9070
		*TM_ROTAXIS -0.4284	-0.4284	-0.7956
		*TM_ROTANGLE 1.7975
		*TM_SCALE 1.0000	1.0000	1.0000
		*TM_SCALEAXIS 0.0000	0.0000	0.0000
		*TM_SCALEAXISANG 0.0000
	}
	*NODE_TM {
		*NODE_NAME "Spot01.Target"
		*INHERIT_POS 0 0 0
		*INHERIT_ROT 0 0 0
		*INHERIT_SCL 0 0 0
		*TM_ROW0 1.0000	0.0000	0.0000
		*TM_ROW1 0.0000	0.0000	1.0000
		*TM_ROW2 0.0000	-1.0000	0.0000
		*TM_ROW3 -19.4201	0.0000	-1.9183
		*TM_POS -19.4201	0.0000	-1.9183
		*TM_ROTAXIS -1.0000	0.0000	0.0000
		*TM_ROTANGLE 1.5708
		*TM_SCALE 1.0000	1.0000	1.0000
		*TM_SCALEAXIS 0.0000	0.0000	0.0000
		*TM_SCALEAXISANG 0.0000
	}
	*LIGHT_SHADOWS Mapped
	*LIGHT_USELIGHT 1
	*LIGHT_SPOTSHAPE Circle
	*LIGHT_USEGLOBAL 0
	*LIGHT_ABSMAPBIAS 0
	*LIGHT_OVERSHOOT 0
	*LIGHT_SETTINGS {
		*TIMEVALUE 0
		*LIGHT_COLOR 0.9098	0.9098	0.9098
		*LIGHT_INTENS 1.2500
		*LIGHT_ASPECT 1.0000
		*LIGHT_HOTSPOT 43.0000
		*LIGHT_FALLOFF 45.0000
		*LIGHT_TDIST 0.0000
		*LIGHT_MAPBIAS 1.0000
		*LIGHT_MAPRANGE 4.0000
		*LIGHT_MAPSIZE 512
		*LIGHT_RAYBIAS 0.0000
	}
}

> I'm guessing that no game creators store lights in the model files.
> It doesn't look too hard to add though.

correct. pretty easy. ssg already has an ssgLight entity.

> I would vote for having
> light loading added if possible.
>

just a matter of time before someone adds it.  if you have time, take a try
and send me the patch.  it might be a while before i could get to it.

thanks,
-- Dave McClurg
mailto:dp...@ef...
http://mcdave.cjb.net

[Plib-users] SSG loading lights

[Dan G. <dg...@hp...>]

The different ssg loaders don't seem to load lights for any of
the formats.  Is there any chance of light loading being added
to any of the loaders?  I'm using the 3ds and ASE loaders currently.

I'm guessing that no game creators store lights in the model files.
It doesn't look too hard to add though.  Dave mentioned cleaning up
the loaders and having them use ssgParser.  I would vote for having
light loading added if possible.

Dan

[Plib-users] Particle System

[Ben W. <be...@bg...>]

Hello

I thought I would point out some code for a particle system. There is also a
tutorial found on gamesutra. Here is the link to the code. Make sure to
check out the tutorial too, could be a good thing to implement.

Later Ben

RE: [Plib-users] Plib, OpenGL and particle engines

[G L W. <gl...@ve...>]

> -----Original Message-----
> From: pli...@li...
> [mailto:pli...@li...]On Behalf Of Steve Baker
> Sent: 01 October 2000 21:47
> To: pli...@li...
> Subject: Re: [Plib-users] Plib, OpenGL and particle engines
>
> Once you've done that once or twice, it's kinda boring
> though...does anyone
> have any idea how to turn it into an actual game?  I was
> originally thinking
> of just making it be a 3D version of one of those classic old 2D plumbing
> games (Xpipeman is one that you see on Linux for example).
>

If you don't want to clone pipeman how about having the obstacles appearing
as the level progresses, and/or moving, so that people go into dead ends and
have to back track, and if the appearance rate of new pieces increased I'd
imagine it would get quite frantic in a Tetrisish fashion.

Gavin

-

gl...@ve... - VectorCommand Ltd.
------ gl...@ac... (forwarding) -------

Re: [Plib-users] Plib, OpenGL and particle engines

[Steve B. <sjb...@ai...>]

Risto S Varanka wrote:
 
> Has anybody implemented a particle engine (for fires, explosions,
> smoke, etc.) using Plib? I am trying to make one using ssgVtxTable
> as a particle, but I haven't got too far yet.

I wrote a really simple one for spraying water in an (unpublished)
game based on connecting up pipework.

> As there are examples of particle engines available for OpenGL, I
> started thinking if it would make sense to use raw OpenGL and Plib
> side-by-side for your application. I assume this kind of approach
> could lead to various problems, unless you are pretty sure about
> what you are doing?

Well, you can always derive a class object from ssgLeaf and write
your own 'draw_geometry' function that does whatever OpenGL calls
are needed.

In 'plumber3d' (working title), I was using GL_POINTS as the particles,
so I had a single ssgVTable (this is older code - written while ssgVTable
was still 'trendy') with ALL of the water droplets in it.  This used
100% SSG code - no raw OpenGL.

Since I only animated the positions of the droplets (not colour, texture,
normal, etc), all I had to do was iterate down the array updating the
coordinates of the points.

The biggest problem is updating the bounding sphere so that the droplets
are culled when none of them are in the field of view.

In the case of my game, I expected all the droplets to be in view
pretty much all of the time - so I just gave the ssgVTable an insanely
large bounding sphere and didn't worry about it.

Anyway, I had ~4000 water droplets spurting out of each of two or three
hoses - and still saw reasonable frame rates on Voodoo-2/266MHzAMD.
All I was doing was accellerating them due to gravity - and detecting
when *either* their Z coordinate fell below ground level or they passed
through a small 3D cuboid that was 'catching' them. (At which point they
either lost a point or gained a point and were then teleported back to
the 'outlet' nozzle).  The hardest thing was setting their initial
velocities and positions such that they didn't all fly out in a solid
mass.

> What should I do to the ssgNormalArray and ssgTexCoordArray?

Just leave them un-set. (Don't call setNormals/setTexCoords at all - don't forget
to explicitly disable lighting and texturing in the ssgSimpleState).  If all your
particles are the same colour, only set *one* colour for the entire leaf node...
that saves quite a bit of time.

That's exactly what I do in plumber3d - and it worked out nicely.

Hmmm - maybe I should dump plumber3d into the PLIB examples directory sometime.

It started life as an attempt at a 'puzzle' game - but it's not currently
puzzling.  :-)   I have all the mechanisms to draw a crazy network of pipes
that you can create with simple keystrokes while water is pumped into one
end and spurts out of the other.  The original idea was that you'd have
to route the water around obstacles to connect it up to a predetermined
outlet before you lost too much water....all in 3D of course.

Once you've done that once or twice, it's kinda boring though...does anyone
have any idea how to turn it into an actual game?  I was originally thinking
of just making it be a 3D version of one of those classic old 2D plumbing
games (Xpipeman is one that you see on Linux for example).

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

[Plib-users] Plib, OpenGL and particle engines

[Risto S V. <rva...@cc...>]

Has anybody implemented a particle engine (for fires, explosions,
smoke, etc.) using Plib? I am trying to make one using ssgVtxTable
as a particle, but I haven't got too far yet. What should I do to
the ssgNormalArray and ssgTexCoordArray?

As there are examples of particle engines available for OpenGL, I
started thinking if it would make sense to use raw OpenGL and Plib
side-by-side for your application. I assume this kind of approach
could lead to various problems, unless you are pretty sure about
what you are doing? 

-- 
Risto Varanka | http://www.helsinki.fi/~rvaranka/		
ris...@he...

Re: [Plib-users] Damage to sound hardware

[Steve B. <sjb...@ai...>]

Christian Mayer wrote:

> we'd just have to bewareabout the USA as there's a microwave
> producer guilty for the death of an hamster that a customer put into it
> to dry it after a bath (unless the puts a warning in the manual...).

Actually, I think that's an urban legend - and the original story
was that it was a miniature poodle (a DOG not a hamster) and the
cause of the court case was that in the long list of foods and
cooking times printed on the door of the oven was "Dogs...3 minutes"
(meaning HotDogs - not Canines).  However, even with that modification,
I don't think this is a true story.

I should point out that in using PLIB (which is an LGPL'ed library),
you are accepting the following clauses from the LGPL:

  Quoting from 'LICENSE' in the PLIB root directory:

                            NO WARRANTY
 
  15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO
  WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW.
  EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR
  OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY
  KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE
  IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
  PURPOSE.  THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE
  LIBRARY IS WITH YOU.  SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME
  THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
 
  16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN
  WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY
  AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU
  FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR
  CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE
  LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING
  RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A
  FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF
  SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH
  DAMAGES.

So, if an off-by-one error in the audio library causes a 'click' and
that causes your speakers to explode thereby setting fire to your
house - resulting in a gas pipeline blow-back that takes out your local
plutonium storage facility - which then leaves a poisonous radioactive
cloud encircling the globe - leaving only three humans left alive (You,
me and a lawyer), it'll be YOU that gets sued...not me.

Hmmm - I'd better just go back and look at that replay routine *one*
more time!   :-)

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

Re: [Plib-users] Damage to sound hardware

[Steve B. <sjb...@ai...>]

Risto S Varanka wrote:
> 
> I gather it is possible to damage your audio hardware, eg. the
> speakers, if you for example turn the volume high enough and play
> some clicks or noise. I imagine this could happen with badly
> coded / pre-alpha / prototype applications.

I guess it's theoretically possible with really high powered amplifiers
and such - I've never heard of anyone actually doing that though.

> How do you guard against this using Plib, so you can avoid
> problems with your users?

I don't - it's really impossible to write a bullet-proof check without
doing some realtime signal analysis - and that's really not going to
happen while the computer is busy doing graphics, etc.

In the end, if your amp/speakers are set up in such a way that damage
could occur, then it could happen because a program crashed - or you
played back an MP3 that had a click in it - anything really.

I just don't think you should worry about it.  If you are overdriving
your speakers to that degree then it's all your own fault IMHO.

> Should you always set your safetyMargin
> high enough and check that you get the same from getRate etc. for
> your slSample and slScheduler?

Safety margin should certainly be set to the longest expected interval
between calls to the SL update routine - or else there can be gaps
in the audio stream.  It's hard for an application writer to get that
right because in a multitasking system, another program could come along
and lock up the CPU for a couple of seconds...so sound breakup is
always a possibility.

Again though, this is nothing unique to PLIB's sound replayer - it could
happen with any of them.

It's a good idea to ensure that your sounds are sampled at the same rate
that they will be replayed - or else they'll be too fast or too slow.
In most applications, you'll be shipping the sound files with the program,
so you can just record them at a suitably high speed and have PLIB downsample
them for you.

> (Btw, what would happen if you call
> slSample::adjustVolume in a loop?)

Not good - the quality of the audio will gradually degrade due to roundoff
errors.  The sample adjust routines make a permenant change to the actual
sound sample data itself.

If you need runtime volume/frequency control, use a one-step slEnvelope
which is applied as the sound is replayed.

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

Re: [Plib-users] Damage to sound hardware

[Risto S V. <rva...@cc...>]

> IMHO it's not the task of PLIB to protect the user/speaker from such
> sounds. 

Indeed, as it seems unfeasible. I was asking what one can do on
the application level to avoid nasty surprises - I was not supposing
the library could be foolproof. 

-- 
Risto Varanka | http://www.helsinki.fi/~rvaranka/		
ris...@he...

Re: [Plib-users] Damage to sound hardware

[<Va...@t-...>]

Risto S Varanka wrote:
> 
> I gather it is possible to damage your audio hardware, eg. the
> speakers, if you for example turn the volume high enough and play
> some clicks or noise. I imagine this could happen with badly
> coded / pre-alpha / prototype applications.
> 
> How do you guard against this using Plib, so you can avoid
> problems with your users? Should you always set your safetyMargin
> high enough and check that you get the same from getRate etc. for
> your slSample and slScheduler? (Btw, what would happen if you call
> slSample::adjustVolume in a loop?)

IMHO it's not the task of PLIB to protect the user/speaker from such
sounds. There are two reasons:

1) it's technically too complex and would consume too much CPU for
something that nearly no application needs. We'd need to add a 'noise
detection' that most probably would require some sort of fourier
transformation - or we would need to scale the volume down generally.
Both sollutions wouldn't be wanted by our customers (i.e. the
application programmers) as there are quite a lot real time programmers
(they need every bit of the CPU). And a downscaled volume would force
the programmers to scale the sound up before he sends it to SL - due to
the limited precition we'd loose quality.

2) If the application destroys the speakers it's the applications fault,
not ours. We didn't provide the sound - we are just passing it to the OS
which is passing it to the soundcard wich is passing it to the speakers.
So we also should require the OS and the soundcard to protect the
speakers (oh, and the speakers should protect themselves, too)
IMHO it's ridiculous to make a library guilty for destroying the
speakers; we'd just have to bewareabout the USA as there's a microwave
producer guilty for the death of an hamster that a customer put into it
to dry it after a bath (unless the puts a warning in the manual...).
Both examples show that the problem lies somewhere else.

CU,
Christian

[Plib-users] Damage to sound hardware

[Risto S V. <rva...@cc...>]

I gather it is possible to damage your audio hardware, eg. the
speakers, if you for example turn the volume high enough and play
some clicks or noise. I imagine this could happen with badly
coded / pre-alpha / prototype applications. 

How do you guard against this using Plib, so you can avoid
problems with your users? Should you always set your safetyMargin
high enough and check that you get the same from getRate etc. for
your slSample and slScheduler? (Btw, what would happen if you call
slSample::adjustVolume in a loop?)

-- 
Risto Varanka | http://www.helsinki.fi/~rvaranka/		
ris...@he...

Re: [Plib-users] Building simple PLIB example? (1.2.0, VC6)

[Wolfram K. <w_...@rz...>]

Ben wrote:

>ssg.lib(ssgStateSelector.obj) : error LNK2001: unresolved external symbol
>"void __cdecl sgMakeCoordMat4(float (*
>const)[4],float,float,float,float,float,float)"

sgMakeCoordMat4 is a function in sg.lib.

>Now, the example project file (tux_example.dsp) only links with the
>"ssg.lib" library, not the other libraries.  Is this wrong?

Yes, also add sg.lib.

>Thanks,
>Ben
>http://vterrain.org/

Bye bye,
Wolfram Kuss.

[Plib-users] Building simple PLIB example? (1.2.0, VC6)

[Discoe, B. <ben...@in...>]

I just downloaded and tried to build a PLIB example this evening, and was
unable to do so.  I'm using VC6 on Win2k.

I downloaded the "stable" plib source version 1.2.0, and it built fine.

Then i looked for an example to see the library in action.  There were no
examples corresponding to version 1.2.0, so i downloaded the closest
version: "plib_examples-1.1.8.tar.gz".

Trying to build the "tux_example" program brought up a lot of problems with
incorrect include and link paths in VC6.  I fixed the path problems, but
still got 115 link errors like this:

ssg.lib(ssgStateSelector.obj) : error LNK2001: unresolved external symbol
"void __cdecl sgMakeCoordMat4(float (*
const)[4],float,float,float,float,float,float)"
ssg.lib(ssgStats.obj) : error LNK2001: unresolved external symbol "void
__cdecl sgMakeCoordMat4(float (*
const)[4],float,float,float,float,float,float)" 

etc.

Now, the example project file (tux_example.dsp) only links with the
"ssg.lib" library, not the other libraries.  Is this wrong?

Thanks,
Ben
http://vterrain.org/

[Plib-users] Problems with puInput

[tjones <tj...@is...>]

Hello Alex

Sorry for not writing sooner, but I am not a member of this mailing list and
I don't know alot about pui yet, but since nobody else answered I thought
that I would try to help and forward the message to someone who knows.
Your Code:
  if((ptype & PUCLASS_INPUT)==PUCLASS_INPUT){
    ((puInput *)pob)->acceptInput();
    pob->setValue(vdefault);
    pob->setLegend(vdefault);
    //    pob->setStyle(PUSTYLE_SMALL_BEVELLED);
    pob->setCallback( cb_net_input_c );
  }

One thing I think could be the problem is the ptype, I asume that is the
name of your class, if so then it should be something like
ptype->getType() & PUCLASS_INPUT. Have a look at the puFilePicker class, it
has a few examples in it about the types in it, there is nothing to do with
puInput but it may help you. I will try to find more information for you
about this, but look there you should see what I am talking about, goto the
cvs on the sourceforge page. In the src/pui directory look at puFilePicker.

Sorry I could not be more specific.
Ben


<ALEX>

Hi,

I am using puInput Fields in the Net-Part of my GuiMenu (see screenshot
tuxfleet.sourceforge.net/gifs/screenshot-gui-connect.gif)

The puInput Fields react on keypresses, I can move, edit, delete, when I
press return this puInput field gets deactivated, and another one
gets activated and the callback function called.

But I couldn`t get to react puInput on Mouseclicks.

Any idea what I could have done wrong?

I got plib from cvs, but found no puInput examples there.
(I also noticed that doc/index.html is somehow Steve Baker`s private
index
page from woodsoup, and not the plib index page?)

For my puInput, I`ve done (see
tuxfleet.sourceforge.net/doxygen/html/class_GuiMenu.html#a15)
  if((ptype & PUCLASS_INPUT)==PUCLASS_INPUT){
    ((puInput *)pob)->acceptInput();
    pob->setValue(vdefault);
    pob->setLegend(vdefault);
    //    pob->setStyle(PUSTYLE_SMALL_BEVELLED);
    pob->setCallback( cb_net_input_c );
  }
and (see tuxfleet.sourceforge.net/doxygen/html/class_Engine.html#a31)
    glutKeyboardFunc       ( keyboard_c ) ;
    glutSpecialFunc ( special_c);
    glutMouseFunc(mouseevent_c);
    glutMotionFunc(motionevent_c);
    glutPassiveMotionFunc(motionevent_c);

Any ideas what I missed?



Alex

Re: [Plib-users] More than four samples playing ?

[Steve B. <sjb...@ai...>]

Michael Wessels wrote:
> 
> Hi all,
> in my program I am using ssl and I am intersting to play more than 4
> samples in the same time.
> What does I have to change in the ssl-sources for this ?
> Who can give me the answer ?

When I wrote SL, it was on a 33MHz 486 - so performance was kinda
critical!  Hence I wrote separate routines for mixing one, two, three
and four samples.  That got the time to play four sounds down to about
7% of the CPU time - which seemed acceptable...so I stopped there.

On modern CPU's, the amount of time consumed by SL is almost too small
to measure - so we could comfortably rip out the carefully coded and
optimised code and just use some simple 'for' loops instead...allowing
users to play as many sound samples at one time as they feel like
expending CPU time on.

The existing routines are not exactly simple though because they are
doing software volume control - as well as pitch-changes, envelopes,
etc.

I think it's worth doing this rewrite of the inner guts of SL - but
I certainly don't have time to attack it myself.

At this point, I have to wonder whether we wouldn't be better off
latching onto a *standard* for doing this stuff - and right now, the
best bet appears to be OpenAL.

So, I'm even more reluctant to attack the innards of SL if we are
likely to toss it all away and use OpenAL anyway.

This is a hard call...but since I don't (personally) have either the
time or the immediate inclination to implement either option...it's
going to depend on who does want to work on it.

FWIW, I don't think OpenAL is quite ready for 'prime time' use yet...
but it's showing signs of becoming something very neat.  I'd certainly
like to play with putting 'sound nodes' into SSG at some future time
because OpenAL has spatialised 3D sounds.


-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

[Plib-users] More than four samples playing ?

[Michael W. <michael.wessels@z.zgs.de>]

Hi all,
in my program I am using ssl and I am intersting to play more than 4
samples in the same time.
What does I have to change in the ssl-sources for this ?
Who can give me the answer ?

With regards

Michael

Re: [Plib-users] bump maps

[Steve B. <sjb...@ai...>]

"Christopher K. St. John" wrote:
> 
> Steve Baker wrote:
> >
> > That gets us into the whole business of
> > supporting multiple texture maps - which *is* a big deal.
> >
> 
>  The multitexture interfaces appear, on the surface, to be
> pretty straightforward. I've played around with multitexture,
> but haven't gone beyond a few very simple hacks, so I've
> likely missed the messier cases. Which areas do you see as
> especially problematic?

Things like going through *ALL* the ssgLeaf routines and
adding support for a variable number of texture coordinate
sets.

Having the lazy-evaluation ssgState mechanisms support
an arbitary number of ssgTextures per state.

Then it's basically true to say that there are exactly
zero common 3D file formats that support multiple texture
coordinates - so we'd probably have to support glTexGen
for some textures and not on others (so the number of texture
maps wouldn't necessarily equal the number of texture coordinate
sets)...

Then you get into all the complications of how maps can
affect each other.

All of this without impacting single-map performance for
existing applications any more than we absolutely have to.

So, although it's not hard to understand at the OpenGL
level, it seems to be *far* from simple at the SSG level.

However, this is DEFINITELY something we need for the
future.

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

Re: [Plib-users] bump maps

[Christopher K. S. J. <cs...@qu...>]

Steve Baker wrote:
> 
> That gets us into the whole business of
> supporting multiple texture maps - which *is* a big deal.
> 


 The multitexture interfaces appear, on the surface, to be
pretty straightforward. I've played around with multitexture,
but haven't gone beyond a few very simple hacks, so I've
likely missed the messier cases. Which areas do you see as
especially problematic? 


-cks

Re: [Plib-users] bump maps

[Steve B. <sjb...@ai...>]

Larry Hess wrote:

> Has anyone try do bump map with plib

Not that I know of.

It's hard to do portably - but for some specific cards, it's not
all that hard...you could probably do it without a change to PLIB
if you have GeForce because it's just a matter of setting some state
in the pre-draw callback and undoing those changes in the post-draw.

The biggest issue is that you rarely want *just* a bump map - typically
you need a colour map also.  That gets us into the whole business of
supporting multiple texture maps - which *is* a big deal.

This is clearly something we have to address though - graphics cards
are increasingly supporting more and more sophisticated multi-pass
renderers.

In order to do this portably, I think we'll need to implement a 'shader
language'...something along the lines of SGI's new shader-compiler - which
I believe was just added to Performer.


-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

[Plib-users] bump maps

[Larry H. <va...@gt...>]

Has anyone try do bump map with plib

Re: [Plib-users] Pre/Post draw callbacks on ssgBranches.

[Steve B. <sjb...@ai...>]

Jon Anderson wrote:

> >Hence, I think you'll have to call the tesselator function for some region
> >around
> >the intersection inside both isect and hot member functions.
> 
> Actually, since the terrain has a pointer to all the height field data. I
> have been just referencing that data directly, rather than trying to
> intersect the resulting mesh.

Excellent idea.  That should be *really* fast too.  The only 'gotcha'
is that applications can demand that you tell us which triangle was
intersected - it's vertices, etc.  I guess you just have to fake it
so that you give back three terrain height posts.
 
> >Incidentally, I'm assuming this is something that we'd put into ssgAux rather
> >into the main scene graph API - since not everyone will want it.  So we'd
> >better
> >talk about ssgaTerrain rather than ssgTerrain.
> 
> Sure.  This is definitely more of a auxiliary.  It's a pretty simple
> implementation right now, with limited flexibility.  Maybe I'll try
> implementing some things like the variance calculation function as call
> backs to allow an end programmer to customize it better.

Yes - I think that would be useful...of course you could donate it as-is
and set the bazaar loose on those improvements!

                  "Commit early - Commit often"

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

Re: [Plib-users] Pre/Post draw callbacks on ssgBranches.

[Jon A. <jan...@on...>]

>
>So why don't you do the tesselation inside the 'cull' function of the
>ssgTerrain?  After you've done tesselating, you can just call:
>
>      ssgBranch::cull( {whatever} );
>
>...to do the actual culling of the daughter objects.

Yes, after poring over the ssg code last night, I think I'll do this.


>
> > I have some misc. utility functions defined like getHeight(), but I'd 
> like to
> > make it work for ssgHOT, etc.
>
>Right - those typically need "exact" answers - irrespective of how the terrain
>is currently triangulated in the visuals.  Also, the terrain may not have
>been triangulated by ROAM if that patch has never been in the field of view.
>
>Hence, I think you'll have to call the tesselator function for some region 
>around
>the intersection inside both isect and hot member functions.

Actually, since the terrain has a pointer to all the height field data. I 
have been just referencing that data directly, rather than trying to 
intersect the resulting mesh.

>
> > Anyway, you can take a look at the code.
>
>With pleasure.
>
>Incidentally, I'm assuming this is something that we'd put into ssgAux rather
>into the main scene graph API - since not everyone will want it.  So we'd 
>better
>talk about ssgaTerrain rather than ssgTerrain.

Sure.  This is definitely more of a auxiliary.  It's a pretty simple 
implementation right now, with limited flexibility.  Maybe I'll try 
implementing some things like the variance calculation function as call 
backs to allow an end programmer to customize it better.

>Maybe I should 'donate' the "feature placement" code from TuxAQFH or TuxKart
>too.  That's a parser for a simple file format that contains names of objects
>and their location in the world - with the option to have them 'planted' onto
>the terrain in Z - and optionally in Roll/Pitch also.

That would definitely be cool.  In fact, I was just about to the point of 
adding that to my little "Walk a quake2 character around on a ROAM terrain" 
game.  =)



Jon

Re: [Plib-users] Pre/Post draw callbacks on ssgBranches.

[Steve B. <sjb...@ai...>]

Jon Anderson wrote:

> I've posted the code at:
> http://innovation3d.sourceforge.net/roam
> 
> I also put up some screenshots so you could see how it looks so far.  =)

Looks good!

> I'll try to explain how it works.
> 
> The ssgTerrain is a sub class of ssgBranch.  It basically is a loose
> encapsulation of ssgPatches, which are what contain the ROAM logic.   I used a
> branch rather than a leaf, because I thought it would be conceptually nice to
> be able to add other things to the terrain, such as buildings, trees, etc.
> This might also allow the terrain to tesselate a little higher around those
> objects, if needed.

Ah!  *Now* I see why it needs to be a branch.

(For the uninitiated - since the terrain polygons in ROAM are constructed
on-the-fly depending on the amount of detail is needed (as a function of
range, etc) - the actual polygonal surface is in fact flexing up and down
as you move towards it.  This is (hopefully) set up so you can hardly
see it happening.  HOWEVER, if a tree or a house is planted onto the
terrain - and the terrain flexes like that, it can leave a noticable gap
beneath the object or bury it underground.  Those things are VERY noticable,
so it's possible to tell the ROAM algorithm to keep more terrain detail
around places where 3D objects are placed - specifically to avoid this
artifact.)

> Each patch is:
> 1) An ssgVtxTable representing a quad for the water line.
> 2)  A TriTree structure attached to the ssgVtxTable as user data.  It is the
> TriTree that is actually used in ROAM.
> 
> The actually patch is rendered in a PostDraw callback registered on the
> VtxTable. This way when the VtxTable is culled, the patch isn't rendered.
> 
> The ssgTerrain is added to the scene in the normal manner.  But in the update,
> it's all rendered by:
> t->reset();    //resets all the patches
> t->tesselate();  //tesselates all the patches.
> ssgCullAndDraw( root );
> 
> Because the tessellation occurs outside the CullAndDraw, all patches are
> tessellated, even those who are culled later.

So why don't you do the tesselation inside the 'cull' function of the
ssgTerrain?  After you've done tesselating, you can just call:

     ssgBranch::cull( {whatever} );

...to do the actual culling of the daughter objects.
 
> I have some misc. utility functions defined like getHeight(), but I'd like to
> make it work for ssgHOT, etc.

Right - those typically need "exact" answers - irrespective of how the terrain
is currently triangulated in the visuals.  Also, the terrain may not have
been triangulated by ROAM if that patch has never been in the field of view.

Hence, I think you'll have to call the tesselator function for some region around
the intersection inside both isect and hot member functions.
 
> Anyway, you can take a look at the code.

With pleasure.

Incidentally, I'm assuming this is something that we'd put into ssgAux rather
into the main scene graph API - since not everyone will want it.  So we'd better
talk about ssgaTerrain rather than ssgTerrain.

This fits in really nicely with the FGFS Sky porting effort.

Maybe I should 'donate' the "feature placement" code from TuxAQFH or TuxKart
too.  That's a parser for a simple file format that contains names of objects
and their location in the world - with the option to have them 'planted' onto
the terrain in Z - and optionally in Roll/Pitch also.

With all of those things provided, writing the graphics part of simple outdoor
games would be a snap.

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

Re: [Plib-users] Pre/Post draw callbacks on ssgBranches.

[Jon A. <jan...@on...>]

> > Well, when I first started, I attached all the Terrain and the Patches as
> > user data on a ssgBranch and ssgVtxTable, respectively.  That  was okay to
> > get it up an running, but made it clunky to use.
> 
> Yes - I can imagine.  It would also be hard to eliminate the problem of
> people attaching 'conventional' ssgVtxTables to the Terrain's ssgBranch
> node - which could be messy!  Obviously you can tell people not to do
> that - but it would be nicer if that was something the compiler could
> just toss out.
>  
> > >Can I see the code?  It would be easier to discuss.
> > 
> > I'll post it somewhere tonight.
> 
> Thanks.

I've posted the code at:
http://innovation3d.sourceforge.net/roam

I also put up some screenshots so you could see how it looks so far.  =)

I'll try to explain how it works.

The ssgTerrain is a sub class of ssgBranch.  It basically is a loose
encapsulation of ssgPatches, which are what contain the ROAM logic.   I used a
branch rather than a leaf, because I thought it would be conceptually nice to
be able to add other things to the terrain, such as buildings, trees, etc. 
This might also allow the terrain to tesselate a little higher around those
objects, if needed.

Each patch is:
1) An ssgVtxTable representing a quad for the water line.  
2)  A TriTree structure attached to the ssgVtxTable as user data.  It is the
TriTree that is actually used in ROAM.  

The actually patch is rendered in a PostDraw callback registered on the
VtxTable. This way when the VtxTable is culled, the patch isn't rendered.

The ssgTerrain is added to the scene in the normal manner.  But in the update,
it's all rendered by:
t->reset();    //resets all the patches
t->tesselate();  //tesselates all the patches.
ssgCullAndDraw( root );

Because the tessellation occurs outside the CullAndDraw, all patches are
tessellated, even those who are culled later.

I have some misc. utility functions defined like getHeight(), but I'd like to
make it work for ssgHOT, etc.

Anyway, you can take a look at the code.

Jon