[Papervision3D] Procedurally generated models

[jakelewis]

IMHO materials are totally separate from Models. A list of all available
materials is stored on a singleton class. When a loading model references a
material it checks this single repository which either returns a previous
material if it already exists or generates a new one. This allows multiple
models to share the same material and allows a model to change material if
needed.
The same idea is needed for texture maps, as it is vital (for memory
reasons) that materials that share a texture map all reference the same map,
even if they are loaded from different files.
Its handy to have the same for models, cameras etc because as the scene
grows it makes searching for things easier. Thus only one cube (per color)
would be stored in the database and multiple references made of it.
A very simple database is what we are talking about - just a set of name
searchable arrays.

This will really help fill out the Collada importer, as forward references
are often made in Collada to objects that have not yet been created.


The glitch you I assume you are referring to - at oblique angles the surface
looks like its made of (rectangular) honeycomb - is a result of z-ordering.
It looks to me like you are rendering both the inside and outside of each
cube, and at these oblique angles the inside of a side panel is being
rendered after the top panel. Easiest solution is to ensure that all the
faces of a cube face out and disable double sided rendering/enable back face
culling. It should also (more or less) double the framerate ;)

gotta go to work now, Jake
  -----Original Message-----
  From: Papervision3D-bounces at osflash.org
[mailto:Papervision3D-bounces at osflash.org]On Behalf Of Pete Hobson
  Sent: Friday, January 05, 2007 8:24 AM
  To: Papervision3D at osflash.org
  Subject: Re: [Papervision3D] Procedurally generated models


  Indeed. Looking through the ASE import code i think it assumes one
material per scene at the moment? I was assuming when Collada import is more
mature, it would handle multiple objects with a material each, and i would
take my guide from how this is implemented... I guess doing it manually
though I can store my materials in a static reference for my class and then
ensure each is only added the once - not sure how a generic add would handle
duplicate materials...


  Really looking forward to child objects BTW - would be nice to blast those
gifs into showers of cubes ;)




  On 5 Jan 2007, at 13:50, John Grden wrote:


    dood that's cool! LOL, what a great idea

    as for the materials thought - that's very interesting. Jake was just
telling me how to some shade spoofing with 8 different versions of the xwing
map I did. Based on rotation, one of the 8 would be used on the model.

    My thought is, I like having the materials for an object stored WITH the
object


    On 1/5/07, Pete Hobson < pete at 99lives.co.uk> wrote:
      Hi All,


      As I dont have any 3d modeling experiance at all, right now im
particularly interested in procedurally generated models such as the
PaperPlane example included in the last release.


      I've made a little (very un-optimized) class which iterates over a
bitmap, and creates colored cubes for each pixel, not useful in itself but
cetainly good for understanding how models are represented in P3D.
      demo - http://www.freesome.com/flobs/papervision3Dextrude1.swf
      class - http://www.freesome.com/flobs/Sprite3D.as


      A couple of questions from this experiment...


      1) Materials. At the moment each pixel is represented by a cube with
six materials (varying shades of the pixel color - until we have lights). I
store each of these generated materials, then have a method to push all
these materials into the scene. Question - would it make sense to add a
"materials" array to DisplayObject3D which would automatically be added to
the scene when the object is added?


      2) Glitches. At certain rotations the join marks of the individual
cubes are visible - i'm guessing this is as im not sharing vertices between
adjacent cubes - this is intentional as once we have child-objects i want to
be able to manipulate each cube seperatly - is there any way round the
glitch other than having a separate shared vertex version for when all cubes
are in their default position?


      Great stuff everyone - the most fun i've had alone in my office for
years ;)




      Pete







      _______________________________________________
      Papervision3D mailing list
      Papervision3D at osflash.org
      http://osflash.org/mailman/listinfo/papervision3d_osflash.org






    --
    [ JPG ]
    _______________________________________________
    Papervision3D mailing list
    Papervision3D at osflash.org
    http://osflash.org/mailman/listinfo/papervision3d_osflash.org


  Pete Hobson
  Interaction Developer
  pete at 99lives.co.uk
  +44 208 123 6974





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://osflash.org/pipermail/papervision3d_osflash.org/attachments/20070105/e69176ea/attachment.htm