gdalgorithms-list

Re: [Algorithms] GUIDs

[Neal T. <ne...@ps...>]

  From: Matthew Davies=20
  Does anyone know the algorithm or have source code describing the way =
CoGuidCreate or UuidCreate generates the GUIDs?  Or perhaps there's a =
cross platform solution to generating globally unique identifiers?


  I believe a GUID is the same as a Free Software Foundation UUID, in =
which case you might want to look at:

  http://www.opennc.org/onlinepubs/9629399/apdxa.htm

  (specification plus algorithms for generating UUIDs)
  =20
  Neal Tringham (Sick Puppies)

  ne...@ps...
  ne...@em...

RE: [Algorithms] ProgMesh LOD function.

[Tom F. <to...@mu...>]

That's all I do, and yes, it's not great. You could build a table of object
space error (as determined by QEM or whatever your edge-collapse function
is) vs number of tris. Then from the screen-space BB and a screen-space
error value, and the object-space bounding sphere radius, you can find the
object-space error required. Look that up in the table, and you know how
many tris you should draw. The table doesn't have to be very precise - my
feeling is that 16 entries is going to be enough - maybe a few more - and
then linearly interpolate between those values.

I've not tried this, but I think I will - the current method (num_tris =
tweak_factor * BB_screen_area) is not wonderful.

Tom Forsyth - Muckyfoot bloke.
Whizzing and pasting and pooting through the day.

> -----Original Message-----
> From: Timur Davidenko [mailto:ti...@3d...]
> Sent: 19 July 2000 19:50
> To: gda...@li...
> Subject: [Algorithms] ProgMesh LOD function.
> 
> 
> I`m trying to come up with good lod function for progressive 
> mesh reduction,
> i have all progressive mesh collapses precalculated so can`t 
> use per vertex
> screen error function,
> i need something more general for complete mesh, function 
> which says how
> many percents of mesh should be cut down
> currently i just taking screen space area of mesh bounding 
> box, dividing by
> some kludge const, but it works badly for different mesh scales.
> any ideas?
> 
>   regards.
> 
> _______________________
>  Timur Davidenko.
>  3Dion Inc. (www.3dion.com)
>  e-mail: ti...@3d...
> 
> 
> 
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> 

Re: [Algorithms] GUIDs

[Davide P. <da...@pr...>]

Does anyone know the algorithm or have source code describing the way
CoGuidCreate or UuidCreate generates the GUIDs?  Or perhaps there's a cross
platform solution to generating globally unique identifiers?

MSDN library samples...

VC98\mfc\utility\guidgen

Davide Pirola

www.prograph.it
www.protonic.net

Re: [Algorithms] 3DS woes.

[Neal T. <ne...@ps...>]

Leigh McRae <lei...@ro...> writes:
>   Yuppers.  I am using the Max R3.1 and the export plugin.  I will look at
> the code and try the switch your talking about.  I find the whole thing
> wierd as MAX will read the file back in correct.  So what do others do
when
> it comes to MAX, write thier own plugin?

I'd suggest either that or using the ASE ASCII exporter.  As far as I recall
we concluded that the .3ds format couldn't actually support all the things
that could be done in Max anyway (its really a 3D Studio rather than a 3D
Studio Max format, I think).

Neal Tringham (Sick Puppies)

ne...@ps...
ne...@em...

[Algorithms] GUIDs

[Matthew D. <MD...@ac...>]

Hi,
 
Does anyone know the algorithm or have source code describing the way
CoGuidCreate or UuidCreate generates the GUIDs?  Or perhaps there's a cross
platform solution to generating globally unique identifiers?
 
Regards,

Matt J. Davies 
Programmer 
Acclaim Studios Ltd. 
Lansdown Road, 
Cheltenham, 
Gloucestershire, 
United Kingdom, 
GL50 2JA. 

Tel: +44 (0) 1242 533 682 
Fax: +44 (0) 1242 533 700 

 

[Algorithms] LightWave Texture reference object mapping algorithm

[Davide P. <da...@pr...>]

Hi !

I'm trying to mapping the UV coordinates of a mesh with both surface panel
texturing
parameters and texture reference object.

All the stuff works fine, but the source code is somenthing like this :
(Example for a planar mapping)

---WithOut RefObject :

vertex -= texture center;

vertex.x = axis / texture center * .5
vertex.y = axis / texture center * .5

(ok... I don't remember exactly the code :-))) )

--- With RefObj

vertex -= (texture center + refObj.translate);
vertex.rotate(refObj.rotation);

vertex.x = axis / texture center*refObj.scaling * .5;
vertex.y = axis / texture center*refObj.scaling * .5;

(Hmmmmmm...Ok... I don't remember exactly the code :-))) ) (Again....)
:-))))

Well... I world like to know is there is a matrix version of the stuff
above.

Somenthing like this : MappedVertex = VertexCoordinates * MatrixOfMapping;

Davide Pirola

www.prograph.it
www.protonic.net

RE: [Algorithms] Byte Swapping

[Eugene F. <fo...@dr...>]

If you're writing to the Mac (or even just have the QuickTime SDK
installed), there are some handy endian-swapping macros in Endian.h.
They're of the form (using unsigned longs as an example)

	EndianU32_?to?(value)

where the characters in the question marks are L (for little endian), B (for
big endian), and N (for native format).  Thus, since your data files are in
big endian format you could write

	EndianU32_BtoN(value)

which would do a conversion when compiled for Intel and compile to nothing
for PPC.  Endian.h uses ConditionalMacros.h to figure out whether you're
compiling for big or little endian.

The only problem is that they don't automatically use CodeWarrior's
intrinsic functions mentioned earlier by Jens Ayton.  I've found that
CodeWarrior lets me get away with the following code, which is in my
precompiled header:

#include <Endian.h>
#undef Endian32_Swap
#define Endian32_Swap(value)                 \
        ( *(uint32*)&(value) = __lwbrx( (uint32*)&(value), 0 ) )
#undef Endian16_Swap
#define Endian16_Swap(value)                 \
        ( (value) = __lhbrx( &(value), 0 ) )

-----Original Message-----
From: gda...@li...
[mailto:gda...@li...]On Behalf Of Michael
S. Harrison
Sent: Tuesday, July 18, 2000 5:30 AM
To: gda...@li...
Subject: Re: [Algorithms] Byte Swapping


hehe.

True.  That comment reflects the fact that all of our basic data files are
in Motorola format and have to be converted when running on the PC

At 10:48 AM 7/18/00, you wrote:


----- Original Message -----
From: Michael S. Harrison
To: gda...@li...
Sent: Tuesday, July 18, 2000 1:17 AM
Subject: Re: [Algorithms] Byte Swapping

[ SNIP ]
/* these assume that the swapping is from motorola to intel format */


[ SNIP ]



...or vice versa ;-))))

Are,
F

Re: [Algorithms] 3DS woes.

[Jonathan B. <jo...@bo...>]

Leigh McRae wrote:

>   Any help on getting a model out of MAX would be much appreciated and I can
> give my semi-broken code out if it helps fix it.

I would not bother with .3ds files.  It's an old format and is 
not useful for much.

What I did was start with the "ascii exporter plugin", the source for which
is in the MAX sdk.  It is incredibly easy to start with this plugin and
modify it to output whatever file format you want.  Or, you could just
parse the ascii output that this plugin provides.

Look in maxsdk/samples/impexp/asciiexp.

   -Jonathan.

RE: [Algorithms] Re: Network Security (was Asus to release 'cheat ing' drivers! on the DXDev list)

[Steve W. <Ste...@im...>]

That's the way we do it.  Be sure to reference players by something other
than their names, or dis-allow players with the same name (a switch if you
provide both). Also, if you are compiling some neat statistics then allow
them to be saved so the server owner can use them for continued statistics
on games played...a simple comma delimited text file with quotes around each
value and a header record works fine...plus provide a means for your server
to launch a program that the server owner has built or installed to process
the statistics.

You might also want to look at half-life TFC which allows the statistics to
be sent via tcp/ip to a destination of choice (usually an independent
tournament or stats server).  Plus, TFC uses a master server that all
players logon to when they start the game...it verifies their CD key and
issues a unique number which is delivered to the game server...then the game
server can track the player via the unique number and output stats that can
be accumulate over spans of games.

R&R

> -----Original Message-----
> From: Jim Offerman [mailto:j.o...@in...]
> Sent: Wednesday, July 19, 2000 1:13 PM
> To: gda...@li...
> Cc: Developer-only Forum for DirectX programming issues
> Subject: [Algorithms] Re: Network Security (was Asus to release
> 'cheating' drivers! on the DXDev list)
> 
> 
> This response is kinda of topic for the DXDev, so I am taking 
> it over to the
> algorithms list...
> 
> I have done some thinking about network security and all, 
> since the last
> thread on this subject over on the algorithms list. I finally 
> came down to
> the following solution:
> 
> Have the server maintain statistics maintain some key 
> statistics from all
> players (nr. of bullets fired, nr. of enemies killed, speed, distance
> travelled, how the health of each player changes over time) 
> and display
> these statistics at the end of the game. Since all the statistics are
> calculated on the server, it will be quite hard for people to 
> cheat them
> (assuming we're not dealing with mastermind hackers). Be sure only to
> include statistics which are _primarily_ controlled by the 
> server (i.e.
> monitoring a player's health makes sense only when the server 
> decides when
> the player is dead or alive, since only then will the client 
> be forced to
> send accurate information to the server in order to participate in the
> simulation).
> 
> Note that the system does not prevent players from cheating 
> (i.e. it won't
> detect Asus' new 3D SeeThrough technology and other 
> client-side cheats). It
> does however, enforce a form of social control by presenting 
> all the players
> with figures about the performance of themselves and other 
> players. If one
> of your competitors in the game manages to work through some 
> masacre with a
> 150% health all the way and kill ten times as many enemies as 
> all the other
> players together, he is either fit to replace Bruce Willis in 
> Die Hard IV or
> he is definitely cheating...
> 
> Again, you can never be a 100% certain that the guy in 
> question is actually
> cheating (it might even be Bruce Willis...), but you do offer all your
> players (and the people maintaining the servers) some means 
> to verify if
> they are dealing with a potential cheater or not.
> 
> Any comments?
> 
> Jim Offerman
> 
> Innovade
> - designing the designer
> 
> ----- Original Message -----
> From: "Grills, Jeff" <jg...@OR...>
> To: <DIR...@DI...>
> Sent: Wednesday, July 19, 2000 9:33 PM
> Subject: Re: Asus to release 'cheating' drivers!
> 
> 
> > In online games, you simply can never trust the client.  
> It's fairly easy
> > for people to write proxy-servers that capture all the 
> information coming
> > across the network connection and display it conveniently 
> on a second
> > monitor (perhaps with a top-down view).  Or they'll hack the windows
> socket
> > layer on their machine.  Or they'll write programs that 
> look through the
> > memory space of the actively running game.  Or a million 
> other ways to
> > extract that data from your game that you can't currently predict.
> >
> > If the client shouldn't be able to see it, the server 
> shouldn't tell the
> > client about it.  You really have no other secure options.
> >
> > jefftep
> > Jeff Grills
> > Director of Technology
> > Origin Systems, Inc.
> >
> > -----Original Message-----
> > From: gl [mailto:gl...@NT...]
> > Sent: Wednesday, July 19, 2000 2:14 PM
> > To: DIR...@DI...
> > Subject: Re: Asus to release 'cheating' drivers!
> >
> >
> > I remember some discussion about that (here?) - something 
> to the effect of
> > capturing a screen shot at random intervals, then analyzing 
> the picture to
> > see if it is intact.  There was also talk of uploading this 
> image (or
> parts
> > of it) to a server, so that it could verify everything was 
> ok.  Very messy
> > though.
> >
> > If this really becomes a problem we'll have to look a 
> little closer into
> the
> > 'zero overdraw' algorithms...
> > --
> > gl
> >
> > ----- Original Message -----
> > From: "Richard Collins" <Ma...@ST...>
> > To: <DIR...@DI...>
> > Sent: Wednesday, July 19, 2000 8:01 PM
> > Subject: Re: Asus to release 'cheating' drivers!
> >
> >
> > > Interesting, I wonder if there is a way we can detect 
> these drivers. I'm
> > > surprised that no one has done this yet to the DX libs 
> like Intel have
> > > done for GPT ( IPeek ).
> > >
> > > -----Original Message-----
> > > From: gl [mailto:gl...@NT...]
> > > Sent: 19 July 2000 19:36
> > > To: DIR...@DI...
> > > Subject: Asus to release 'cheating' drivers!
> > >
> > >
> > > I just read this on RivaStation
> > > (http://www.rivastation.com/index_e.htm),
> > > and it is an absolute outrage:
> > >
> > >
> > > 7/19/00 ASUS for cheaters?
> > > ASUS announced a new tool called 3D SeeThrough (TM). This 
> tools allows
> > > you
> > > to make walls transparent or play in a wireframe more. A 
> present for
> > > cheaters !?! Heres the PR Taiwan, Taipei July 18, 2000: ASUSTeK
> > > Computer,
> > > Inc. announces its new secrete weapon for AGP-V7700 and 
> AGP-V7100 series
> > > graphics cards - the 3D SeeThrough TM technologies. "ASUS always
> > > provides
> > > the best value for our customers." said Jonathan Tsang, 
> vice president
> > > of
> > > marketing and sales division of ASUSTeK Computer Inc. "The ASUS 3D
> > > SeeThrough TM technologies are developed for users to be 
> a constant
> > > winner
> > > in the adventure or action 3D games. There are three 
> special weapons for
> > > ASUS VGA cards' users - Transparent View, Wireframe View, 
> and Extra
> > > Light.
> > > If you do not have an ASUS VGA card - be careful! Never 
> compete in the
> > > 3D
> > > games with anyone who has an ASUS VGA card. Because the 
> only result is
> > > to
> > > loose"
> > >
> > >
> > > As a long time FPS player, the client-side bots did 
> enough to damage
> > > trust
> > > amongst players - these drivers would effectively kill 
> most types of
> > > real-time on-line gaming!  As developers, I suggest you 
> all voice your
> > > opinions in the strongest possible way to Asus and try to 
> prevent them
> > > from
> > > releasing these drivers 
> (http://www.asus.com.tw/company/support.html)!
> > > I
> > > 
> mean, really, how can they be this stupid?  If the PC is 
> going to become
> > > compromised this way, then roll on X-Box...
> > > --
> > > gl
> > >
> >
> > 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> >  FAQ Location: http://msdn.microsoft.com/library/techart/dxfaq2.htm
> >  Web Interface: 
> http://DISCUSS.MICROSOFT.COM/archives/DIRECTXDE> V.html
> >  
> Problems/Suggestions: 
> DIR...@di...
> >  Use the Web Interface (above) to unsubscribe from the list.
> >  Use plain-text only. Home page: http://www.microsoft.com/DirectX
> >  MSDN DirectX Developer Centre:  http://msdn.microsoft.com/DirectX
> > 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> >
> 
> 
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> 

Re: [Algorithms] Optimization

[Gil G. <gg...@ma...>]

> This may be borderline off-topic for this list...  If you agree, please
respond directly to me to avoid spamming the list.
>
>
> I was wondering what some of you are doing for PC optimization of your
C/C++ code?  More specifically, I'm wondering how you're leveraging your
tools (compiler, etc) when you don't have the bandwidth to run through and
hand optimize all of your code.  What compilers are you using to get the
best optimization (I'm stuck with VC6), what optimizations have you found to
be safe and fast, and what optimization have you found to be dangerous?
>

Well, we use VC6 and we find it does a very good job at the default
"release" settings. We use VTune to profile actual gameplay situations. When
we locate a hot spot, usually it is an algorthmic problem (hence your
question isn't off-topic). Some performance problems aren't really
algortihmic, and VTune provides further information. For example, VTune is
the ultimate tool for seeing how well VC did with the code generation. VC
usually generates excellent asm. The crappy memory subsystem on the PC is
more likely to show up as the culprit and in this case you might consider if
your data could be reorganized or compressed.
-Gil

[Algorithms] Re: Network Security (was Asus to release 'cheating' drivers! on the DXDev list)

[Jim O. <j.o...@in...>]

This response is kinda of topic for the DXDev, so I am taking it over to the
algorithms list...

I have done some thinking about network security and all, since the last
thread on this subject over on the algorithms list. I finally came down to
the following solution:

Have the server maintain statistics maintain some key statistics from all
players (nr. of bullets fired, nr. of enemies killed, speed, distance
travelled, how the health of each player changes over time) and display
these statistics at the end of the game. Since all the statistics are
calculated on the server, it will be quite hard for people to cheat them
(assuming we're not dealing with mastermind hackers). Be sure only to
include statistics which are _primarily_ controlled by the server (i.e.
monitoring a player's health makes sense only when the server decides when
the player is dead or alive, since only then will the client be forced to
send accurate information to the server in order to participate in the
simulation).

Note that the system does not prevent players from cheating (i.e. it won't
detect Asus' new 3D SeeThrough technology and other client-side cheats). It
does however, enforce a form of social control by presenting all the players
with figures about the performance of themselves and other players. If one
of your competitors in the game manages to work through some masacre with a
150% health all the way and kill ten times as many enemies as all the other
players together, he is either fit to replace Bruce Willis in Die Hard IV or
he is definitely cheating...

Again, you can never be a 100% certain that the guy in question is actually
cheating (it might even be Bruce Willis...), but you do offer all your
players (and the people maintaining the servers) some means to verify if
they are dealing with a potential cheater or not.

Any comments?

Jim Offerman

Innovade
- designing the designer

----- Original Message -----
From: "Grills, Jeff" <jg...@OR...>
To: <DIR...@DI...>
Sent: Wednesday, July 19, 2000 9:33 PM
Subject: Re: Asus to release 'cheating' drivers!


> In online games, you simply can never trust the client.  It's fairly easy
> for people to write proxy-servers that capture all the information coming
> across the network connection and display it conveniently on a second
> monitor (perhaps with a top-down view).  Or they'll hack the windows
socket
> layer on their machine.  Or they'll write programs that look through the
> memory space of the actively running game.  Or a million other ways to
> extract that data from your game that you can't currently predict.
>
> If the client shouldn't be able to see it, the server shouldn't tell the
> client about it.  You really have no other secure options.
>
> jefftep
> Jeff Grills
> Director of Technology
> Origin Systems, Inc.
>
> -----Original Message-----
> From: gl [mailto:gl...@NT...]
> Sent: Wednesday, July 19, 2000 2:14 PM
> To: DIR...@DI...
> Subject: Re: Asus to release 'cheating' drivers!
>
>
> I remember some discussion about that (here?) - something to the effect of
> capturing a screen shot at random intervals, then analyzing the picture to
> see if it is intact.  There was also talk of uploading this image (or
parts
> of it) to a server, so that it could verify everything was ok.  Very messy
> though.
>
> If this really becomes a problem we'll have to look a little closer into
the
> 'zero overdraw' algorithms...
> --
> gl
>
> ----- Original Message -----
> From: "Richard Collins" <Ma...@ST...>
> To: <DIR...@DI...>
> Sent: Wednesday, July 19, 2000 8:01 PM
> Subject: Re: Asus to release 'cheating' drivers!
>
>
> > Interesting, I wonder if there is a way we can detect these drivers. I'm
> > surprised that no one has done this yet to the DX libs like Intel have
> > done for GPT ( IPeek ).
> >
> > -----Original Message-----
> > From: gl [mailto:gl...@NT...]
> > Sent: 19 July 2000 19:36
> > To: DIR...@DI...
> > Subject: Asus to release 'cheating' drivers!
> >
> >
> > I just read this on RivaStation
> > (http://www.rivastation.com/index_e.htm),
> > and it is an absolute outrage:
> >
> >
> > 7/19/00 ASUS for cheaters?
> > ASUS announced a new tool called 3D SeeThrough (TM). This tools allows
> > you
> > to make walls transparent or play in a wireframe more. A present for
> > cheaters !?! Heres the PR Taiwan, Taipei July 18, 2000: ASUSTeK
> > Computer,
> > Inc. announces its new secrete weapon for AGP-V7700 and AGP-V7100 series
> > graphics cards - the 3D SeeThrough TM technologies. "ASUS always
> > provides
> > the best value for our customers." said Jonathan Tsang, vice president
> > of
> > marketing and sales division of ASUSTeK Computer Inc. "The ASUS 3D
> > SeeThrough TM technologies are developed for users to be a constant
> > winner
> > in the adventure or action 3D games. There are three special weapons for
> > ASUS VGA cards' users - Transparent View, Wireframe View, and Extra
> > Light.
> > If you do not have an ASUS VGA card - be careful! Never compete in the
> > 3D
> > games with anyone who has an ASUS VGA card. Because the only result is
> > to
> > loose"
> >
> >
> > As a long time FPS player, the client-side bots did enough to damage
> > trust
> > amongst players - these drivers would effectively kill most types of
> > real-time on-line gaming!  As developers, I suggest you all voice your
> > opinions in the strongest possible way to Asus and try to prevent them
> > from
> > releasing these drivers (http://www.asus.com.tw/company/support.html)!
> > I
> > mean, really, how can they be this stupid?  If the PC is going to become
> > compromised this way, then roll on X-Box...
> > --
> > gl
> >
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>  FAQ Location: http://msdn.microsoft.com/library/techart/dxfaq2.htm
>  Web Interface: http://DISCUSS.MICROSOFT.COM/archives/DIRECTXDEV.html
>  Problems/Suggestions: DIR...@di...
>  Use the Web Interface (above) to unsubscribe from the list.
>  Use plain-text only. Home page: http://www.microsoft.com/DirectX
>  MSDN DirectX Developer Centre:  http://msdn.microsoft.com/DirectX
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>

[Algorithms] Optimization

[Michael S. H. <mic...@ud...>]

This may be borderline off-topic for this list...  If you agree, please respond directly to me to avoid spamming the list.


I was wondering what some of you are doing for PC optimization of your C/C++ code?  More specifically, I'm wondering how you're leveraging your tools (compiler, etc) when you don't have the bandwidth to run through and hand optimize all of your code.  What compilers are you using to get the best optimization (I'm stuck with VC6), what optimizations have you found to be safe and fast, and what optimization have you found to be dangerous?

I'm also thinking that the responses might form the basis of a FAQ for future newbies.



  Michael Harrison
  United Developers / Inertia, LLC
  Director of Development
  Development Lead for RC Simulator
  214-855-5955 x 102
  Work log @ http://lynx.inertiagames.com

[Algorithms] ProgMesh LOD function.

[Timur D. <ti...@3d...>]

I`m trying to come up with good lod function for progressive mesh reduction,
i have all progressive mesh collapses precalculated so can`t use per vertex
screen error function,
i need something more general for complete mesh, function which says how
many percents of mesh should be cut down
currently i just taking screen space area of mesh bounding box, dividing by
some kludge const, but it works badly for different mesh scales.
any ideas?

  regards.

_______________________
 Timur Davidenko.
 3Dion Inc. (www.3dion.com)
 e-mail: ti...@3d...

Re: [Algorithms] 3DS woes.

[Leigh M. <lei...@ro...>]

  Yuppers.  I am using the Max R3.1 and the export plugin.  I will look at
the code and try the switch your talking about.  I find the whole thing
wierd as MAX will read the file back in correct.  So what do others do when
it comes to MAX, write thier own plugin?

Leigh McRae

----- Original Message -----
From: Robert Dibley <RD...@ac...>
To: <gda...@li...>
Sent: Wednesday, July 19, 2000 12:10 PM
Subject: RE: [Algorithms] 3DS woes.


> > I have a  house.3ds file that is basicly a box and roof but the
> > roof never lands on top of the house.  If I join the roof and box then
it
> > works ok.
>
> Are you by any chance using the MAX exporter that writes 3DS files ?
> If so, then that may be your problem - when I looked at it, it seemed to
be
> bugged.  Something to do with using the wrong matrix I think.  Something
> like GetNodeTM being used where GetObjectTM should have been perhaps ?
>
> hope thats some small help,
>
> Robert
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
>

RE: [Algorithms] 3DS woes.

[Robert D. <RD...@ac...>]

> I have a  house.3ds file that is basicly a box and roof but the
> roof never lands on top of the house.  If I join the roof and box then it
> works ok.

Are you by any chance using the MAX exporter that writes 3DS files ?
If so, then that may be your problem - when I looked at it, it seemed to be
bugged.  Something to do with using the wrong matrix I think.  Something
like GetNodeTM being used where GetObjectTM should have been perhaps ?

hope thats some small help,

Robert

[Algorithms] 3DS woes.

[Leigh M. <lei...@ro...>]

  Sorry if OT but I have spent way too long on this 3ds exporter thing.

  I wrote some code to read a 3ds file and things work for the most part.  I
have the basic models and texture mapping working right but somethings
wacked.  I have a  house.3ds file that is basicly a box and roof but the
roof never lands on top of the house.  If I join the roof and box then it
works ok.  I do know that there is a local matrix in the file but using it
every which way but loose doesn't help.  The NVidia toolkit viewer also
doesn't show the roof right.  Is this a common thing?  I also looked into a
MAX plugin but there doesn't seem to be much docs on this.

  Any help on getting a model out of MAX would be much appreciated and I can
give my semi-broken code out if it helps fix it.

Leigh McRae

RE: [Algorithms] Real-Time Shadows

[Akbar A. <sye...@ea...>]

there's been a lot of papers and demos on that one.
but here's a hint of advice.
imho, hard shadows are totally nasty and ugly.
point light sources are very rare in real life.
check www.nvidia.com/developer for the nvshadow demo. mark wrote up a paper
on it too.

if you have realtimerendering check the shadow chapter. it gives a very
clear way to do this.
>In my case, I am using Quake II
>models as my characters, each of which is composed of 500~1000 >
>>>>polygons.
looks like you won't be doing to much coding for the shadows.
also check out the quake clone demo on nvidia's site. it takes the quake 2
models' and casts shadows.
including shadow volumes.


peace.
akbar A.



-----Original Message-----
From: gda...@li...
[mailto:gda...@li...]On Behalf Of
Pai-Hung Chen
Sent: Tuesday, July 18, 2000 3:47 PM
To: gda...@li...
Subject: [Algorithms] Real-Time Shadows


Hi,

I am palnning to use traditional Shadow Volume technique to generate dynamic
shadows.  Can anyone help me start on how to calculate shadow polygons
(bounding polygons of the shadow volumne) in the world space?  (I use
Direct3D.)  Also, I am wondering if shadow volume is the right choice for
real-time 3D games to generate shadows.  In my case, I am using Quake II
models as my characters, each of which is composed of 500~1000 polygons.
Can someone in-the-know tell me how shadows are typically generated in 3D
RPG games?

BTW, can someone point me to any tutorials detailing how to calculate
object's silhouette and then build shadow volume from it?

Thank you,

Pai-Hung Chen



_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

[Algorithms] I want to import something from quake2(3)

[<zz...@26...>]

   I'd like to test something about character and bsp.
   Any resource about the format of quake2/3 's datafile is 
prefered.   Or any links to others' work?
   Thanks in advance.

Jason Zhang

_____________________________________________
һ·ÉÏÓÐÄ㣬¿àÒ»µãÒ²Ô¸Ò⣡
--ΪÄãϲ°®ÓëÖ§³ÖµÄ263Ê׶¼ÔÚÏߣ¨http://www.263.net£©Í¶Ò»Æ±£¡
ÎÒҪͶƱ£¡£¨http://fsurvey.cnnic.net.cn/survey/index.html£©

RE: [Algorithms] Real-Time Shadows

[Steve W. <Ste...@im...>]

> From: Pai-Hung Chen [mailto:pa...@ac...]
> 
> Can anyone help me start on how to calculate shadow polygons
> (bounding polygons of the shadow volumne) in the world space?

I guess just a start would be a common suggestion that I've heard for
shadows...drawing just the objects that will create shadows onto a back
surface with the camera positioned to where the light will be that you want
to create shadows for while using a darker texture than what the object
normally has, then blitting that "shadow" into your world.  The drawbacks
are that you have to figure out which objects are in front of which for each
light...not the kind of thing you want to do in real-time, unless you just
have a ceiling light and just want a shadow on the floor from players.

That's about all I know, and I haven't worked out any of the details for it.

R&R

Re: [algorithms] Polygon reduction & texture

[Ales M. <ja...@sl...>]

Stan has a plug-in for 3dsmax that preserves texture coordinates,
material,... Look on his web page for the plug-in, he recently released the
code for it too. It's all there:))

Good man Stan:)

----- Original Message -----
From: mandor <ma...@sd...>
To: Algorithms List <alg...@3d...>
Sent: Tuesday, July 18, 2000 1:09 PM
Subject: [algorithms] Polygon reduction & texture


> Hi
> I'v implemented the polygon reduction algo described by S. Melax in
> gdmag (ok, it was easy: he gives the source code :) ). But now, I have
> to texture the reduced object, and I was wondering what was the common
> approach in this case...?
>
> Thx
>
> Mandor
>
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

RE: [algorithms] Polygon reduction & texture

[David N. <ma...@je...>]

> Hi
> I'v implemented the polygon reduction algo described by S. Melax in
> gdmag (ok, it was easy: he gives the source code :) ). But now, I have
> to texture the reduced object, and I was wondering what was the common
> approach in this case...?
>
> Thx
>

In my LOD module you can flag out with a mask as NOT collapsable  vertices
with certain properties, like having different material, border vertices,
smoothing groups, different uvs, etc... This is because my aproach (and
almost anybody's for the sake of api efficiency) is NOT generating new
vertices.

The only real problem is educating artists to make them know how things work
and to use that knowledge to get better quality LOD.

Regards

David Notario

[Algorithms] Real-Time Shadows

[Pai-Hung C. <pa...@ac...>]

Hi,

I am palnning to use traditional Shadow Volume technique to generate dynamic
shadows.  Can anyone help me start on how to calculate shadow polygons
(bounding polygons of the shadow volumne) in the world space?  (I use
Direct3D.)  Also, I am wondering if shadow volume is the right choice for
real-time 3D games to generate shadows.  In my case, I am using Quake II
models as my characters, each of which is composed of 500~1000 polygons.
Can someone in-the-know tell me how shadows are typically generated in 3D
RPG games?

BTW, can someone point me to any tutorials detailing how to calculate
object's silhouette and then build shadow volume from it?

Thank you,

Pai-Hung Chen

Re: [Algorithms] C++ inherited constructors

[Adam M. <amo...@dp...>]

>You can always make the ctor throw an exception, which is an acceptable
form
>of error handling in this case.

I did say exactly that in my message.  Please read more carefully.

--
--Adam Moravanszky


>> That, together with the fact that constructors can't return error codes
>> (only throw exceptions) when something goes wrong, has me following a
very


>> --
>> --Adam Moravanszky
>> http://www.n.ethz.ch/student/adammo

Re: [Algorithms] Octree leaf neighbours

[<SHA...@ao...>]

In a message dated 16/07/00 19:19:50 !!!First Boot!!!, sa...@ip... writes:

<< John,
 
 I'm sure I mean six. Above,Below,Left,Right,Forward and Back. (Don't care
 about diagonals).
 
 Yes I am recursing through the tree, and yes each node is "in play" during
 the traversal. But I'm doing a "marching cubes" type of thing, I need to
 share vertices between nodes. To do that I need to look at my neighbours,
 see if they have been processed, and if so use their vertex instead of
 generating a new one.
 
 Yeah, If I store a pointer to parent I can traverse "up and round" to find
 my neighbour. But whether this will save me any time over just generating
 new vertices and not sharing. Time to suck it and see.
 
 Thanks,
 
 Sam.
  >>

Sorry about that, I obviously misunderstood your question.

Currently what I do is give every triangle an index number, I don't store the 
actual vertices in the octree.
I then create an array of boolean variables, one for each tri, and set them 
all to false.
When I do the visibility check, if a tri is in a visible node then I flag 
that boolean element to true.
This is done, what I will do next....
Finally when the visibility test is finished, for every tri that has a true 
flag it's 3 verts are copied to a vertex buffer.
The triangles are all random except for one important thing, they are in 
texture order.
This means I will be able to do the minumum amount of settexture renderstates 
since they will all be in order in the vertex buffer, and I will draw them 
with DIPVB.

that's when I get some spare time! :)

Regards,

John.

RE: [Algorithms] texture-based fog idea

[Bass, G. T. <gt...@ut...>]

>How about a link to the bitmap, I'd be interested in looking at it.

As would I :)

Regards,
Garett Bass
gt...@ut...