MUD-Dev
mailing list archive
[ Other Periods
| Other mailing lists
| Search
]
Date:
[ Previous
| Next
]
Thread:
[ Previous
| Next
]
Index:
[ Author
| Date
| Thread
]
[MUD-Dev] Re: How to represent a 3d object...
- To: mud-dev#kanga,nu
- Subject: [MUD-Dev] Re: How to represent a 3d object...
- From: Oliver Jowett <oliver#jowett,manawatu.planet.co.nz>
- Date: Sat, 25 Apr 1998 18:20:42 +1200 (NZST)
- Delivery-date: Tue Apr 24 17:48:07 1998
- Delivery-date: Tue, 24 Apr 1998 17:48:07 -0700
- Envelope-to: claw#kanga,nu
- Reply-To: mud-dev#kanga,nu
- Sender: "Petidomo List Agent,,,," <petidomo#kanga,nu>
On Fri, 24 Apr 1998, Ben Greear wrote:
> I am thinking about how to represent a 3d object in a 3d world.
[...]
> I envision the object as a collections of intersections (nodes) and faces.
> The two big questions are: what kind of data structure should I use for
> in-memory storage, and how to encode this for storage in a persistant
> storage mechanism.
> There must be some standard way of representing this on disk, does anyone
> have any pointers??
A few comments on in-memory formats (be warned, I last looked at this
about 3 years ago):
You can represent the object as a list of vertex locations (nodes), with
the faces being defined as a list of vertex references in some particular
order around the face (so the normal is well-defined). Normally (no pun
intended) you'd precompute the normals of each face to speed things up.
Having the normal ready can help with hidden-face removal, and also speeds
up various shading models if you feel so inclined.
Store the object untransformed, with location/orientation/scale/etc info
separate. It's likely that you'll be changing these parameters frequently
(otherwise: why not just use a static bitmap?) and roundoff errors are a
real killer, unless you really want the Incredible Shrinking Object. This
also makes having multiple instances of a model in different locations
easy.
You'll probably want some sort of bounding box information if the object
is part of a larger world - x/y/z extent information may well be enough if
you don't have obscurely-shaped objects. Very useful for optimizing
display, and for collision detection etc.
There's a large amount of information available on ways to display 3d
objects, which affects how you want to store the data internally -
IIRC the comp.graphics (.algorithms?) FAQ has good references to this
type of thing.
A search dug up <URL:http://www.dcs.ed.ac.uk/~mxr/gfx/3d-hi.html> which
has quite a list of 3d storage formats. You may want to look at one of the
binary object formats for DB storage - OFF seems promising from a quick
glance through. 3d formats tend to like representing complete scenes made
up of lots of objects with huge piles of surface information, so your main
problem may be finding a simple format :)
Question: what environment is this aimed at? Some way to visualise a
particular object (and/or manipulate it) - ie. you're only displaying the
object itself? Hm, this could be a relatively cheap addon to an otherwise
non-3d system - a nice way to visualise and interact with objects carried,
etc.
"Interesting, a strange metallic sphere with three buttons in a triangle
on the top. I wonder what happens if I push the red one. <click> .. I
don't think the way it started flashing is a good thi--"
<boom>
Or are you aiming at displaying an object within a larger 3d world also
containing other objects / walls / avatars / etc?
-O
--
MUD-Dev: Advancing an unrealised future.
- Thread context:
- [MUD-Dev] Motivations (was something else...), (continued)
- [MUD-Dev] How to represent a 3d object...,
Ben Greear greear#cyberhighway,net, Sat 25 Apr 1998, 02:44 GMT
- [MUD-Dev] Re: MAPPING: Creating a bitmaped graphic from map,
John Bertoglio alexb#internetcds,com, Sat 25 Apr 1998, 01:20 GMT
- [MUD-Dev] (fwd) AD: [custom graphical] whitestar Crossfire MUD,
J C Lawrence claw#under,engr.sgi.com, Fri 24 Apr 1998, 18:29 GMT
[ Other Periods
| Other mailing lists
| Search
]