What a Web 3D Project Needs to Start

Web based 3D projects rarely stall on rendering. They stall because nobody decided what the experience covers, or because the model everybody assumed existed turns out to be a construction file that will not open on a phone.

This is the list of what has to exist before production starts, why each item matters, and what the workaround costs when it is missing. It is ordered by consequence rather than by chronology, because the expensive gaps are not the obvious ones.

A decision about coverage, written down

The first document is a list of what the experience will contain, and it is the item most often replaced by a vague intention to show the development.

Which plan types are included, whether every one or a subset. How many views, and from which orientations and which levels. Whether interiors are included and for which plans. Whether amenity spaces appear. Whether price and availability are shown.

That list determines the production schedule, the budget and the timeline. Written down it makes quotes comparable and makes the delivery date real. Left unstated it becomes the thing that expands during production, quietly, until somebody notices the date has moved.

It is also the document that exposes the multipliers early, particularly views across orientations, which is the item that grows fastest and surprises people after the number has been approved.

An honest account of what geometry exists

This is the item that most often turns a comfortable budget into an uncomfortable one, and it is easy to establish in an afternoon.

Does a 3D model exist. Who has it. What was it built for. Has anybody opened it recently and confirmed what state it is in, or is its existence being inferred from the fact that renderings were produced from something.

The common and expensive situation is a project that believes it has a model because the architect works in a modelling application. A coordination model is built for construction and carries structure, systems and detail no browser can deliver to a phone.

Converting that is not an export step. It is a rebuild, and pricing it as a conversion is the single most common way a web 3D budget is understated.

A confirmed drawing set

Where the model has to be built rather than adapted, the drawings are the source and they change more often than anybody plans for.

What is needed is a current set with issue dates, confirmed in writing by somebody with the authority to say which sheet supersedes which. Floor plans, elevations, sections establishing floor to floor heights, and whatever exists of the site and landscape.

The failure this prevents is quiet and expensive. Content produced from a superseded elevation looks finished, passes internal review because nobody compares it to the drawing, and is discovered to be wrong months later when construction makes it obvious.

Where the set is incomplete, the workable approach is to produce what is stable and defer what is not, with an explicit note about which assets are provisional and a plan for revisiting them.

Site and context information

A web experience that shows a building floating on white answers half the question a remote visitor arrived with, and the other half is what is around it.

That requires something about the surroundings: neighbouring buildings at correct height and position, the street, the ground and anything that will remain. Massing accuracy matters more than detail, because the question is relationship rather than appearance.

For a site with real topography, ground levels from survey are needed rather than an assumed plane, since a building sitting on the wrong ground reads as wrong even to somebody who cannot say why.

This is also the content most likely to be omitted for budget reasons and most likely to be missed by a buyer deciding from another state, who has no other way to learn what is next door.

The interaction decision, made early

Whether the experience simply shows the development or lets the visitor do things is a decision that changes the production rather than a setting adjusted later.

A viewer is production work: it is made, it is tested, it is published. An experience where the visitor selects units, compares plans, filters or configures is software, with states, edge cases, a testing burden and years of maintenance.

Deciding late produces the worst outcome, which is a build that acquired interaction incrementally without ever being designed for it, and which behaves unpredictably in the combinations nobody anticipated.

The useful discipline is to name each interaction and the question it answers. Selecting a unit answers a real question. Toggling a time of day usually does not, and both cost the same to build and maintain.

Unit data, cleaned

If the experience shows plans, units or availability, the data behind it has to be in a usable structure, and it never arrives that way.

What is needed is consistent: a unique identifier per unit, plan type, level, orientation, area and status. What projects usually have is a spreadsheet built for a different purpose, with merged cells, inconsistent naming and three units sharing a label.

Cleaning that is a real task, it belongs to nobody by default, and it therefore lands in the final week before launch. Assigning it early with a named owner is unglamorous and it is one of the two things most likely to delay a launch.

A decision about price and availability

Settle this before the build, because it determines whether the experience is a published asset or a live system.

Showing neither leaves the visitor with the one question the experience cannot answer, and they go elsewhere to find it. Showing exact current figures creates an obligation that will be broken within months unless somebody owns it.

The workable middle for most developments is an indicative range, framed clearly as indicative, with an obvious route to a current answer. That satisfies the visitor without creating a maintenance liability nobody will honour.

Where the experience will live

An experience nobody can reach is the most common way this budget is wasted, and the placement decision belongs before the build rather than after it.

Decide which page it sits on, whether it is a primary action or a menu item, whether it appears in the email sequence, whether brokers get the link, and whether advertising points at it directly.

That decision also affects the build, because an experience embedded inside an existing page has different constraints from one occupying its own page, and retrofitting the embed later is real work.

The reference device and connection

Somebody has to name the least favourable realistic case the experience must work on, and it should be named in the brief rather than discovered in testing.

The oldest phone the audience plausibly carries, on a cellular or home connection rather than office wifi, held in daylight rather than in a meeting room.

Naming it early changes production decisions that are expensive to reverse: how heavy the model can be, how much texture detail survives, and how many things can be on screen at once.

Hosting and delivery arrangements

Cheap for this format and frequently unassigned, which produces avoidable delay at the worst moment.

Who hosts the assets, whether they are served compressed, whether the arrangement survives a change of web agency, and who has access to update them.

The question worth answering explicitly is what happens if the relationship with the vendor ends. An experience hosted entirely by a vendor with no source files is a rent rather than an asset, and that should be a conscious choice.

Legal and factual review, scheduled

A web experience is published to the world, which makes its claims more exposed than anything shown in a controlled room.

Views attributed to specific units, distances and travel times, finishes described as included, availability, pricing, and anything implying an amenity that is not committed all warrant review before publication rather than after.

Views are the recurring exposure, because an image showing a specific outlook is a representation about something a neighbouring development can change, and keeping a record of what was published and when is worth the modest effort.

Ownership, agreed in writing

The model outlives the experience, the engine and the agency, and it is the source of every asset the project will produce afterwards.

Owning the source assets in a usable format means the next phase is a derivative, a vendor change is possible, and a design change is a re export rather than a negotiation.

Owning only access to a published experience means every future output starts from nothing, and the leverage to secure the better arrangement disappears the moment the work is delivered.

Analytics decided before the build

This format reports on itself, which is a genuine advantage over every other visualization format and one most projects never use.

Deciding what to measure in advance, rather than adding tracking afterwards, is what makes the data answer commercial questions instead of technical ones.

Which plans were opened, how long people stayed, where sessions ended, how many forwarded the link. Those numbers make the case for the next phase from evidence rather than from preference.

A named owner on the client side

Web projects with no single responsible person on the development side drift, because the decisions required are spread across marketing, sales and the project team and none of them owns the whole.

The decisions that need one voice are unglamorous and constant: which plans are in, what the price framing says, whether a change is worth the delay, and who signs off that a view is acceptable.

Without that person, each question routes to a different stakeholder, answers conflict, and production stops while somebody works out whose opinion governs. That is the most common cause of a schedule slipping without anybody doing anything wrong.

The role does not require technical knowledge. It requires availability and the authority to settle a question in an afternoon rather than in a meeting next week.

A realistic timeline

The model is the long pole and everything else is comparatively fast, which is the opposite of how these projects are usually scheduled.

Model production or rebuild starts as soon as geometry sources are confirmed and runs continuously. Interaction design and integration happen alongside it and are shorter. Testing on real devices happens only when there is something to test, and it is the task compressed when everything else slips.

Legal review should run against content as it completes rather than as one block at the end, since a single objection at the end can hold the whole publication.

What each missing item costs

No coverage decision: production expands quietly and the date moves.

No honest account of geometry: the largest cost appears mid project, after approval.

No confirmed drawings: content built from superseded geometry and rebuilt later.

No context information: a remote buyer cannot learn what is next door and eliminates the development.

No clean unit data: the launch is delayed by a spreadsheet.

No placement decision: an experience nobody reaches.

No ownership clause: the next phase starts from nothing at full price.

The shortest viable starting point

For a development that wants to move quickly, the minimum honest set is a confirmed drawing set, a decision about which plans are covered, ground and context information, a named reference device and an agreement about ownership.

Everything else can be decided during production without holding it up. Those five cannot, because each of them determines work that is expensive to redo.

Gathering them takes days rather than weeks, and it is the difference between a project that ships on the date and one that discovers its real scope in week six.

This guide is part of our wider coverage on the same topic. For the full picture, including scope, pricing and delivery, read How Many Revision Rounds a Rendering Project Needs.

Frequently asked questions

What most often delays a web 3D project?

Two things, neither of them the 3D. An undecided coverage list, which lets production expand quietly, and unit data arriving as a spreadsheet built for another purpose, which belongs to nobody and therefore gets cleaned in the final week.

We have an architect model. Is that enough to start?

Usually not without a rebuild. A coordination model is built for construction and carries structure, systems and detail no browser can deliver to a phone. Converting it is a rebuild rather than an export, and pricing it as a conversion understates the budget.

Do we need context and surroundings?

For a remote audience, yes. A building shown on white answers half the question and the other half is what is around it. Massing at correct height and position matters more than detail, and on real topography ground levels should come from survey.

Should the experience show current pricing?

Showing nothing sends visitors elsewhere and showing exact figures creates an obligation that breaks within months unless somebody owns it. An indicative range clearly labelled, with a route to a current answer, satisfies the question without the liability.

What has to be agreed about ownership?

That the project owns the source model and assets in a usable format rather than only access to a published experience. With ownership the next phase is a derivative and a vendor change is possible. The leverage to secure it disappears after delivery.

What a web 3D project needs to start

A web 3D project puts an interactive model or scene on a website, so visitors can rotate, zoom or explore a product, a building or a space. Before work can begin, the team needs clear inputs and a plan for how the experience will load and run. Rendimension is an architect-directed visualization studio with more than 1,000 projects and a principal with 20+ years in visualization. It has an office in Miami, Florida, a presence in Beverly Hills, California, and delivers remotely across the United States on Eastern time.

Rendimension provides visualization only. It does not provide CAD drafting, engineering or construction documents. This page is a general checklist. It does not promise performance on every device. Rendimension focuses on architectural visualization, and it can supply images and 3D views from approved drawings. Interactive web development is typically done with a web developer.

What to prepare

Purpose and audience

Decide what visitors should do after seeing the scene, such as request a quote, choose a unit or explore a layout.

Source files

Drawings, a 3D model or product files. The cleaner the source, the lighter the web version.

Materials and lighting

Decide the finishes and the mood so the scene feels consistent.

Performance targets

Web scenes must load quickly on phones. Model size, textures and effects all affect speed.

Web models are usually simplified versions of the full model. Fine detail that does not help the viewer is removed to keep loading fast.

A

l

s

o

p

l

a

n

t

h

e

h

o

s

t

i

n

g

a

n

d

e

m

b

e

d

d

i

n

g

.

A

s

k

y

o

u

r

w

e

b

d

e

v

e

l

o

p

e

r

h

o

w

t

h

e

s

c

e

n

e

w

i

l

l

b

e

a

d

d

e

d

t

o

t

h

e

s

i

t

e

a

n

d

t

e

s

t

e

d

.

Common web 3D uses

• Product viewers.
• Interactive floor plans.
• Unit pickers for new developments.
• Virtual showrooms.
• Panorama tours.

Planning the project

Start with a small scope. One clear scene that works well is better than a large one that loads slowly.

Test on a phone and on a slow connection. Many visitors will see the scene on a mobile device.

Decide who updates the scene when the design changes.

Keeping images and drawings aligned

Images are only useful when they match the drawings that will be built. When the design changes, tell the studio at once so it can update the affected views instead of redoing the whole set.

Keep a simple log of approved images, the date of approval and the drawing revision each one is based on. If a question comes up later at a hearing or with a buyer, the log shows which version people saw.

Ask the studio to name files clearly and to deliver full-resolution images plus web-size copies, so the same set serves print, presentations and online listings without extra work.

Plan the review steps in advance. A short preview stage, followed by a clear approval, prevents late changes to lighting, materials or camera angles that would cost another round of revisions.

How to prepare before requesting quotes

• Gather plans, elevations and any 3D model in PDF, CAD or Revit format.
• Collect site photos, a survey or a site plan.
• Write down the audience for the images, such as buyers, tenants, lenders or a review board.
• List the number of views you need and where they will appear.
• Set a deadline and a budget range so the studio can propose a realistic scope.

Studios that receive clear information can quote accurately. Vague requests produce vague quotes, extra revision rounds and surprises late in the schedule.

Typical view list

• Hero view image.
• Interactive scene or panorama.
• Fallback images for slow devices.

What to send the studio

• Drawings or 3D model.
• Material selections.
• Brand colors.
• Target page and device list.
• A short note on who will see the images and what decision they support.

Cost and timeline

Rendimension prices from a written scope, so the figures below are reference points and not a fixed menu.

• Exterior renderings run from $750 to $1,250+ per view.
• Interior renderings start at $1,250 per view.
• Animation starts at $3,500, which suits a walkthrough or fly-around of a finished design.

Delivery is typically 5 to 10 business days from complete files, with two revision rounds included. Larger projects, complex geometry and many views need more modeling time, so the written scope states the schedule before work starts. Ordering a full set of views at once lowers the cost per image, and the same model can later produce extra angles or an animation at a smaller added cost.

How the process works

1. Send drawings, finishes, site information and references.
2. The studio reviews the files and returns questions and a written scope with views, price and delivery date.
3. The studio builds or cleans the model and checks it against the plans and elevations.
4. You approve camera angles, time of day and style from a preview.
5. The studio renders final images, and you can request up to two consolidated revision rounds.
6. The model stays available for later changes, extra views or animation.

How to evaluate a company

• Ask for samples of projects like yours, not only a general portfolio.
• Check that the studio works from your drawings without changing the design.
• Confirm the number of views, revision rounds and delivery formats in writing.
• Confirm usage rights for marketing, financing and approvals.
• Confirm a preview of camera and light before the final render.
• Read the revision terms and ask what counts as a design change.
• Ask about usage rights for websites, social media, print and public meetings.
• Ask who owns the model and whether it can be reused.

Red flags

• A quote that does not list the number of views and revision rounds.
• Prices far below other quotes with no explanation.
• A portfolio with no projects similar to yours.
• Images that change materials or proportions from the drawings.
• No written scope or unclear revision terms.
• No preview stage before the final render.
• Promises that an image will guarantee approval, sales or leasing.
• A price far below every other quote with no explanation.
• A studio that promises permit drawings or construction documents.

Frequently asked questions

Does Rendimension build web 3D apps? Rendimension provides architectural visualization images and views. A web developer handles interactive code.

How long does it take? Typical delivery is 5 to 10 business days from complete files, depending on the number of views.

Do you provide drafting or construction documents? No. Rendimension provides visualization only.

How long does it take? Typically 5 to 10 business days from complete files, with two revision rounds included.

What does a view cost? Exteriors run from $750 to $1,250+ per view, interiors start at $1,250 and animation starts at $3,500, all based on a written scope.

Do you work outside Florida and California? Yes. Rendimension delivers remotely across the United States.

Related guides

• Best architectural CGI companies
• Best exterior rendering companies
• 3D architectural walkthrough services
• Commercial building 3D rendering for developers

Working with Rendimension

1. Send plans, finishes, site information and the purpose of each image.
2. Receive a written scope with views, price and timeline.
3. Approve camera angles and style from a preview.
4. Receive final images and two consolidated revision rounds.
5. Reuse the model for changes, extra views or animation.

If you need images or views for a web project, send your drawings and Rendimension will return a written scope with a price.

Reusing the model

The model built for the first image supports additional views, design updates and animation. Confirm in the scope that the model remains available and ask how updates will be priced. Reuse lowers the cost of every later deliverable and keeps all images consistent as the design evolves.

Presenting the images

Show the hero image first, then walk through the supporting views. Collect feedback in writing and group it into one revision round. Clear communication keeps the project moving and avoids repeated small changes that slow the schedule.