Welcome to the Designer Homes Website

Home | Rules | Assessment Criteria | Tips and Tricks | Removal Policies Home Ranking & Definitions | Preparing for Upload | Code Testing Policy Contact Us

Our purpose at DH is three-fold - to afford builders an opportunity to have their worlds uploaded to CT, to provide builders with comprehensive feedback for learning purposes, & to provide citizens with quality-built homes. When you receive your assessment take the time to go over it carefully & make certain that you address all of the issues specified in doing your revisions. The issues identified are required changes unless otherwise specified - for example, on occasion we make suggestions which are clearly noted as suggestions.

Please note: Quality requirements for a Designer Home upload are much higher then the CT Mall's requirements

What We Watch For:

Section 1 ~ Construction

Textures:

Using transparent materials with textures on IFSs should be avoided as that can create plane-sensing distortions between pieces.   A texture must not be stretched so badly that it is splotchy or pixelly, or scaled with so many repetitions that it appears to be very very busy as this is hard on the eyes.   Where a texture is used in a tiling fashion, it must tile well.   Where possible builders should create their own textures. If the textures used are from another artist, it is required that the textures be copyright free, or that the builder has received permission from the artist to use the texture(s). In the latter case, the World Info must contain the copyright information & the builder must forward detailed information to DH regarding the texture source(s) separately by email or DH Inbox.   If a builder uses UM (Universal Media) textures, the ImageTexture url must be referenced to the CT mirror site URL & not 1. the UM home site URL or URNs, or 2. uploaded in the builder's texture folder.   Textures with 'subject-matter' may not violate CT's content regulations with regard to subject-matter.    Texture tags: only .jpg .gif & .png tags are permitted.   Large file-size textures can also create difficulties for users when they are loading in a world. It is advisable to use the Mall guidelines (20k) for texture file sizes. A small number (1-3) of larger texture files (not exceeding 40k)  may be used.  Exceeding these limits may earn a builder a higher processor-demand usability ranking.  When using UM textures, bear in mind that many have file-sizes which are unworkable for VRML worlds.

Audio Files:

Where possible builders should create their own audio files. If the audio files used are from another artist, it is required that they be copyright free, or that the builder has received permission from the artist to use the file(s). In the latter case, the World Info must contain the copyright information & the builder must forward detailed information to DH regarding the source(s) separately by email or DH Inbox.    Audio files with 'verbal subject-matter' may not violate CT's content regulations with regard to subject-matter.    Large audio file-sizes can also create difficulties for users when they are loading in a world. It is advisable to use restraint in the selection of audio materials - exceeding reasonable limits (approx 40k) may earn a builder a higher processor-demand usability ranking.

Improperly positioned/proportioned pieces & Elevators:

All pieces must be put together so that they meet properly with adjacent pieces leaving no gaps, for example, between floors & walls, where walls meet, between walls & ceilings, between walls & doorframes/doors, between steps in a staircase, between segments of elevation grids used in landscaping, etc.   Where areas of a house/world are inaccessible by walking to them, elevators or 'physical viewpoints' (an active object which when clicked will beam the user to a location) must be provided to transport the user so that they can move to those areas without having to use the viewpoint list.   Windows need to be sized so that the user can see through them, & Balcony Railings need to be sized so that the user can see over them. And unless there is a thematic purpose for such, windows must be sufficiently transparent to view through to the other side, must not have so much specularColour, lights or shininess on them that they white-out when viewed, & should be realistically tinted or tinted in keeping with a world's colour schematics & theme.   Unless gigantism (or liliputism) is part of the world's theme, all pieces need to be properly proportionned with respect to the size of the avatar (which varies from approx 1.6-1.75 metres, 1.75 being the more commonly used definition of avatar height).

Sheering:

Sheering (or smashing) occurs when two nodes (pieces) are placed such that they overlap causing them to argue for visual predominance. The results are jig-jags of each piece emerging in a dynamic exchanging of fragments. For the viewer, fragments of the 2 surfaces involved break through each other. Depending on where the problem occurs, there are a number of possible solutions - for horizontal pieces, thickening the top piece or thinning the bottom piece will work; for vertical pieces, the same or creating an additional piece to hide the effect also works.

Doors:

There are several ways of doing doors & some issues to keep in mind: a collision-free door which utilizes non-collision coding - with this door users simply walk through.    animated door-opening inwards/outwards or sliding to the left/right. When using this method make certain that the doors do not open so slowly that the user has to wait a long period of time to go through it or so quickly that the user has to make multiple attempts to go through. Doors can be coded to open quickly, stay open for a while & then close quickly to overcome usage problems.   animate doors to click to open/click to close (touch sensor), or put doors on a proximity sensor. If using a prox sensor however, make certain that the distance of activation parameters are tight so that the doors are not wildly opening & closing when users are nowhere near the door.    Choose a style of door & use it consistently throughout a world so that users don't have to keep track of which door opens & which they can just walk through.

Landscaping:

Billboard Coding-if billboard coding is used, for example on trees, light standards, plants, care must be taken not to position billboarded items so close to adjacent pieces that they go through the pieces when they are rotating.   Elevation Grids-where multiple grids are positioned to continue a landscape or overlap on a landscape, care must be taken to have the adjoining areas mesh smoothly without gaps or radical breaks (upwards/downwards) in surface levels.   Backgrounds-an effort must be made to use backgrounds which have a presentable resolution to the graphics. If appropriate graphics cannot be found, it is recommended that builders use plain color schematics to define a sky background instead. In addition, it is permissible to mount background graphics on very large pieces - however, care must be taken if assembling pieces to have them meet properly. Background graphics must also tile correctly horizontally & vertically.

Furnishings:

Builders may omit furnishings or include partial furnishings. Due to the level of detail involved & the increase to filesizes, it is not recommended that builders attempt to completely furnish a home.

Section 2 ~ World Issues

Viewpoints:

Viewpoints must be coded so that the level of entry for an avatar has the bottom of the av's foot level with the ground. To check the level of entry, enter the world, don't move, right-click on the screen, choose View My Avatar. Once you move you will see how high or low your av is in relation to the ground level by the way the av jumps up or down to stabilize on the ground. (Average avatar height is 1.75)   Must be named, preferably as descriptively/creatively as possible. Avoid viewpoint names which are words without spaces (example: balconyoverdoor), or simple numerical sequences (example: room1, room2, room3, etc). It is not necessary to separate words in a viewpoint with an underscore_. To name viewpoints in Spazz use the far right tab & put the viewpoint name in the empty box.   Animations which contain viewpoints must unbind when the user exits the proximity of the ride.   Worlds have limited space for the creating of a viewpoint list. Viewpoints in excess will not appear as active links on the viewpoint list (& that will affect any viewpoints which may be added to a world via objects dropped into it). It is recommended that a world contain enough viewpoints to highlight the features of the world.   Viewpoint Tour: the order in which viewpoints appear on the viewpoint list determines the order in which they occur on the viewpoint tour. Care should be taken to present viewpoints for the tour so that the user is not whipped around senselessly from one end of the world to another, instead to organize viewpoints so that they progress in a logical sequence for the tour. It is possible to separate individual viewpoints so that  they appear on the list in a sensible tour order - they do not have to all be clumped together in the coding.

Animations:

All animations must stop, either on their own at the end of the ride, or via a switch, proximity or visibility sensor.   Animations which are rides utilizing a proximity sensor should not be left at the final key outside the front door of the home such that exiting the house causes the user to be involuntarily placed back on the ride. A suggestion for fixing this problem is to set it up so that when the user leaves the proximity of the ride the ride moves away to a remote position.   Ride animations which contain viewpoints must unbind when the user exits the proximity of the ride.   Use of extensive ongoing animations, or blanket animations (animations that can be seen no matter where you are in the world) such as animated large tracts of water for lakes, may earn a world a higher processor-demand ranking. It is not recommended that multiple ongoing animations be built into a world.

Lag:

DH assigns a status (rank) to accepted worlds which is intended to assist buyers with varying computer processing capabilities in determining which worlds are easier or best for them to use. In general, the status groupings represent low, medium, & high processor-demand worlds. Using this system, DH will be able to accept worlds which are more complex & buyers will be able to determine, prior to purchase, if a world is likely to be beyond their comp's capabilities or sufficiently laggy as to impair their enjoyment of the world. Nevertheless, builders are cautioned to use restraint in building complexity into worlds as DH will still reject worlds which are excessively laggy.      It is recommended when using a larger number of complex objects in a world, to separate them on the landscape as much as possible to decrease concentrations of lag in a central area (especially if that central area is the house given that users will also be concentrating their dropped objects in that area).

World Info / Coding:

World Info: World info must contain the name of the world, the name of the builder, copyright & date as well as any external copyright info necessary - you may have to hand code this in. Handcoding code is as follows: WorldInfo { title "House Name here" info [ "any information included needs to be inside quotation marks" "if you start a new line use a new set of quotation marks" "you may use as many lines as you need" ] } The world must contain the CT protos as provided by DH.    Avatar Height ~ Unless there is a specific thematic purpose, avatars must be coded to fall within 1.6-1.75 metres tall (1.75 being the more commonly used height)

Lighting:

Lighting levels must not be so high that the colours of a world (including the default avatar) are washed out or such that distortions occur which are not thematically-based   Lighting levels should not be so low that walls, floors and the ground appear black (except in instances where night conditions are created as part of the world theme). If this happened you may have to add more lights in strategic locations so the areas effected are those which are very dark.

Thumbnails:

The maximum thumbnail size permitted is 512 x 512.   A thumbnail must not be so small that what the world looks like is indeterminable or the writing so small that no one can read it.   The thumbnail size should not exceed 40kb-users have to load these in on viewing pages (properties boxes) as well.   The text included on a thumbnail must be legible.