hi Chris, > First, let me assume you are talking about Max's 'Multi/Sub Object' > material. (If you are simply talking about a 'Composite' material type (a > way to export multitexture data), then just multiple TextureUnitState's > would do.)
you're right I am talking about Max's 'Mutli/Sub Object' metrial.. > So, what we need in this case is what you're talking sort of talking about - > using the same geometric data and a seperate material. you definitly got it. > What I would do (and > will be doing - Multi/Sub support is an important feature in my 3dsmax > exporter) is create another class that keeps track of all these "split" > shape3d's in an extended Shape3D class (MultiShape3D or something) - which > would also implement GeometryUpdater. This class' updateData() method will > also call all contained shape3d's GeometryArray's updateData() method in > turn. Since you will want all transforms between the split geometry to be > identical (to avoid surface tearing and such) this new class can be simply > added as a child of a transform and all the shape3d's within will be thus > transformed. I also have a mesh class that keeps track of the different Shape3Ds (everyone with a unique Appearance) which handles the updates, probalbly the only difference is that I only split the indices and not the vertices for several reasons. 1. I don't have to take care of surface tearing and such 2. It avoids addiotional geometry, because splitting geometry at trinagles with different materials for the edge vertices would let to more vertices (the reasong why surface tearing can occur) 3. Every per vertex data - I have GeometryUpdater that behaves like Max's Skin or Physqiue Modifier - would also increase. > Btw. I've never tried it personally, but it seems from all I've read that > Indexed(Quad/Tri/TriStrip)GeometryArray is a much worse choice than > (Quad/Tri/TriStrip)GeometryArray, since java3d must un-indexify the data > before sending it to the card. Or conversely, if you use the beta j3d, the > USE_COORD_INDEX_ONLY combined with indexed arrays should be quick. converting to USE_COORD_INDEX_ONLY will be an option in my exporter - currently I', doing this during import. > That's my 3 cents. That's my 3 euro-cents. ;-) > http://www.geocities.com/Psionic1981 for an early, early demo of my upcoming > java3d based game. IMHO players are too small, perhaps you can integrate a dynamic camera (remembering a dreamcast game such as yours with that) and absolute paths (C:\3DSMax..) are a pain. but rest looks fine :-) greetings -Michael Nischt > > >From: Michael Nischt <[EMAIL PROTECTED]> > >Reply-To: Discussion list for Java 3D API <[EMAIL PROTECTED]> > >To: [EMAIL PROTECTED] > >Subject: Re: [JAVA3D] Geometry Update > >Date: Mon, 1 Apr 2002 23:06:19 +0200 > > > >Hi Doug, > > > > > This will work in the current implementation, but it is technically > > > one of those "undefined behavior" cases. > > > >in case david's suggestion isn't safe for the future - I hope there will be > >an 'official' way, beause I don't know how to handle 3DSMax's > >MutiMaterials > >of a mesh instead > >and I need to share the vertices for effiecient vertex blending.. > > > >greetings > >-Michael Nischt > > > > > > > > > > > > Doug Twilleager > > > Java 3D Team > > > Sun Microsystems > > > > > > >Subject: Re: [JAVA3D] Geometry Update > > > >To: [EMAIL PROTECTED] > > > >MIME-version: 1.0 > > > >Delivered-to: [EMAIL PROTECTED] > > > > > > > >Ooh this is a good one! > > > > > > > >Since it is considered illegal to update the vertices of by-ref > >geometry > > > >outside of a geometry updater it would be "bad" to do as you have > >suggested. > > > >However, I am not sure if it would actually be a problem if you do this > >from > > > >a behavior since I would expect that both geometry array's would > >already > >be > > > >winging their way to the card. But if you wanted to play it safe, try > > > >making a dummy updator that does nothing but invoke the other updater > >on > >the > > > >other geometry array. This should lock both at the same time. You > >could > > > >even build a generic class that could manage "shared by-ref geometry" > >to > > > >provide this locking. > > > > > > > >Dave Yazel > > > > > > > >-----Original Message----- > > > > > > > >From: Michael Nischt [mailto:[EMAIL PROTECTED]] > > > >Sent: Monday, April 01, 2002 1:16 PM > > > >To: [EMAIL PROTECTED] > > > >Subject: [JAVA3D] Geometry Update > > > > > > > > > > > >hello everyone, > > > > > > > >I have an question concerning geometry-update, with shared vertices: > > > > > > > >Two (Indexed)GeometryArrays (BY_REFERENCE) share the same vertices > >(with > > > >different indices), because some parts have different Materials. > > > >I decided to put the same cordinate/normal arrays in both and I update > >one > > > >with a GeometryUpdater, and both were updated correct. :-) > > > > > > > >But I am wondering if this legal, because the second one has no > > > >GeometryUpdater ? do I have to put an dummy updater for the second one > >? > > > > > > > >greetings > > > >-Michael Nischt > > > > > > > >btw. a Test application is attached for better understanding > > > > > > > > > > > > > > > > > > > >=========================================================================== > > > To unsubscribe, send email to [EMAIL PROTECTED] and include in the > >body > > > of the message "signoff JAVA3D-INTEREST". For general help, send email > >to > > > [EMAIL PROTECTED] and include in the body of the message "help". > > > > > _________________________________________________________________ > Send and receive Hotmail on your mobile device: http://mobile.msn.com > > =========================================================================== > To unsubscribe, send email to [EMAIL PROTECTED] and include in the body > of the message "signoff JAVA3D-INTEREST". For general help, send email to > [EMAIL PROTECTED] and include in the body of the message "help". =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA3D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
