CompuServe Messages

Hi Sanford and everyone, I was negligent by not responding to messages in a timely fashion yesterday, so here goes: I enjoyed your virtual office, etc. from NAMGUB.ZIP. It was really neat to see someone else put forth effort and creativity for what some may consider a silly notion. I, as well as you, would really like to see this whole idea fly. I posted my suggestion for a team project back on 11/19, but got no direct responses, in part due to the fact that I had used "Help with explode .axp" as my subject/respond to message header. There is obviously interest on the forum now. I offered my services as zoning coordinator back then. I'm a little confused with some of your recent messages regarding what you hope to incorporate into the city vs. what may be tongue-in-cheek. There are some very important organizational issues to address for such an undertaking, and I feel I have some good ideas. What I need from you is some feedback on what you think our roles should be. Perhaps you could be the city planner responsible for the overall layout of the city, its concept and creation, etc., and I could be the mayor responsible for day to day administration and consensus-finder. No? Well piss off!!! (Maybe I need to work on my consensus-building). I am willing to invest a significant amount of time here and there in this project, and would really like to be directly involved with the set-up. What follows are some of my ideas… 1 MASTER FILE: Forget my original idea of using oldcity.3ds as a starting point. I propose a master .prj file that everyone would download. It would contain an object called "00street", a large 2D rectangle at y=0. It would also contain a large grid similar to yours, which would basically be three types/colors of 2D rectangles representing city blocks, sidewalks, and land parcels. Typical blocks would contain probably four parcels, so that every parcel of these is on a corner (higher visibility) for each person's "flagship" parcel (corporate HQ, personal obsession, etc.). Several blocks should contain smaller parcels, about eight to a block. These would be reserved for other venues that people could request for secondary uses. At the center of each parcel would be a 2D number, two digits. Thus, I propose about 100 parcels (maybe 16 blocks: 8 x 4 parcels plus 8 x 8 parcels) be made available. The master file would also have a sun spotlight (180,180,180), ambients at 10,10,10. All master entities other than the 2D numbers will be assigned a prefix of 00, so as to be at the top of object/light/camera lists. 1.8 to be used as standard gamma for computer monitors. 2. PROCESS: Joe Blow might think parcel 32 would be great for Joe's Garage. He applies to the zoning dude/administrator for it. If its open he gets it, or is maybe referred to a more suitable parcel. He constructs his model, deletes all master file enities except for his 2D object "32" (so downloaders can check for alignment), zips it (32garage.3ds) and a short text file (32garage.txt) up to the Take5 library with the title "StudioCity 32 Joe's Garage", keywords "StudioCity, 32, Garage," etc.. Interested parties merge it into their ever-growing master file. 3. STANDARDS: a. Scale. The master file entities should not be moved or scaled by developers, so as to ensure seamless mergings later. Scale (unit setup) should be set at "Architectural, denominator = 100, 1 unit = 1.0 inch. This is about right for 50PMAN.3DS. The grid should be created from 0,0,0 out NE to whatever, I haven't measured streets and sidewalks lately. People should shoot for life-sized objects. Each large parcel will be about 40 feet by 80 feet, small ones about 20' x 40'??? 50PMAN looks pretty good against these sizes. Try it. People will be able to easily scale pre-built models to the scale of the master file. b. Objects. Developers are to shoot for simple models with low vertice/face counts so as to minimize CIS time and rendering time. Use rectilinear objects as much as possible. Use less than perfect spheres, etc. When ready to go, all objects possible should be attached to lower the object count. c. Materials. Use common maps from the WCTK CD-ROM or the 3DS maps/images directories as much as possible. Keep map use to a minimum. Use sand.cel as a common texture/bump map for objects (low RAM overhead). Same with lawn.cel, refmap.gif, etc. No .sxp's please. Reflective objects OK, we can always select no reflect when rendering. If custom maps are absolutely necessary, upload as small of a .gif or.cel file as you can. No .tga's. Keep in mind that the final project might be put out to video. Avoid dangerous NTSC saturation and luminance. d. Selection sets. Have nothing selected, so as to avoid nasty surprises after merging. e. Mesh colors. Each parcel will be assigned 4 colors to be used to create contrast for mesh viewing, if desired. Will make it easier to delineate parcels too. Master file will have exclusive use of about four colors. Three exclusive colors will also be allocated for high detail meshes across all developers' files for these categories: plants; high-detail critters; and high-detail misc. The combination of assigning seperate prefixes for each parcel, as well as using specific colors for parcels and high-detail meshes should make it easy to hide/unhide objects quickly to minimize rendering times. People can also link interparcel objects in the keyframer, then hide the parent. f. Lights. Besides master lights, each person can use a limited number (2?) of extra lights per parcel. Assign them ranges to stay within your parcel if possible. Avoid shadow-casting spots. Set them up if you want, but turn their shadows off. This way we can render the sunlight shadow alone by default. If you simply need more generic light, do not add them. People will probably create some generic omni lights in their master file. g. Cameras. No more than two per parcel. h. Animation. Sounds fun! Describe it in the text file. Does it add greatly to file size??? 4. DEVELOPMENT IDEAS: If possible, let's aim for a somewhat balanced city (maybe I've played too much SimCity <g>). Sure, we all need our virtual offices/HQ's, but our city needs a variety of other things too: Bars/Restaurants Shopping Industry Vehicles Life forms Offices Recreation City Sevices** ??? ** I've got dibs on the cop shop/donut shop! 5. FEES: Developers will pay a fee of 250 cyberbucks to the zoning commission for each application. Payment will be in cash in the alley behind John's Joint. 6. APPROVAL: Requests for approval of location and use within 48 hours. Everyone gets at least one large parcel and one small parcel. Early birds get the choice downtown locations! Maybe do an exterior first, upload it, then later do the interior at your leisure, then upload it as "32b…" 7. NAMING: All entities (objects, lights. cameras) will need to be named seperately with the parcel number as a prefix. All materials, unless used _exactly_ as they appear in the default 3DS material library, will need the parcel prefix too. Since photorealism doesn't have to be the goal here, the locked ambient and diffuse colors in 3ds matlib wouldn't kill us. Basically, we need to avoid repititous names so we don't get the dreaded "material/object name in use…" and also have an easy way to identify what is who's, where, etc. 8. MISC: I would like to hear any ideas that will make our exchange of files more simple or more accurate. Specifically, are 100 parcels too many? Too few? Is 40' x 80' big enough for large parcels? Too big? Ready to start buildin', Paul D. Sanford Sanford for Mayor Committee Close ties to the mob and local building industry P.S. to Sanford Kennedy: Can these ideas be integrated into what you are currently working on? Could you do the creation of the streets, sidewalks, etc, or would you like me to? Maybe mix up the small and large parcels, putting the large ones on the corners? Are you really planning to do a half dozen or more models? Should we number the entities to three digit prefixes? This town could keep growing forever, not bad to look ahead. I'd love to see an animated walkthrough for next year's SIGGRAPH!