Natural Language to Rendering API Translation

ARX - 2024.11 - 2024.12 (2 months)

Built a semantic translation layer that converts natural language user requests ("make it warmer," "add sunset lighting") into precise rendering API parameters. The system uses large language models for intent parsing, parameter extraction, and context-aware rendering suggestions. Includes validation, error handling, and feedback loops for improving translation accuracy.

NLPOpenAIAnthropicPythonFastAPIAPI DesignPrompt Engineering

Background

Modern architectural rendering APIs offer powerful capabilities but require technical expertise to use effectively. Parameters like color temperature, lighting angles, material properties, and camera positions are expressed as numerical values or technical enums.

For example, to achieve "sunset lighting," a user must manually configure:

  • Sun elevation: 5-10 degrees
  • Color temperature: 2500-3000K (warm orange)
  • Shadow intensity: 0.7-0.9
  • Ambient occlusion: Medium
  • HDR intensity: 1.2-1.5

Problem: This technical barrier prevents designers from focusing on creative decisions and slows down iterative workflows.

Solution: Build a natural language interface that translates user intent into precise API parameters automatically.

Responsibilities

  • NLP Pipeline Design (100%): Architected the intent parsing and parameter mapping system
  • Prompt Engineering (100%): Designed prompts for GPT-4/Claude to extract user intent accurately
  • API Integration (100%): Built the translation layer between NLP outputs and rendering API
  • Validation & Error Handling (100%): Implemented parameter validation and fallback strategies
  • Feedback Loop System (100%): Designed mechanisms to improve translation accuracy over time

Technical Architecture

The system consists of four main components:

1. Intent Parser

Extracts semantic meaning from user requests using large language models.

Input: Natural language string (e.g., "make the building warmer tones")

Process:

  • Send request to GPT-4/Claude with context about current render state
  • Extract intent categories: lighting, materials, camera, atmosphere, etc.
  • Identify modification type: increase, decrease, set, toggle
  • Extract target elements: specific objects or global scene changes

Output: Structured intent object

{
  "intent_type": "modify_material",
  "target": "building_facade",
  "property": "color_temperature",
  "modification": "increase",
  "intensity": "medium"
}

2. Parameter Mapper

Translates semantic intent into concrete API parameters.

Uses a knowledge base of rendering parameter ranges:

  • Color temperature: 1000K (cool blue) → 6500K (warm orange)
  • Lighting angles: 0° (overhead) → 90° (horizon)
  • Material properties: roughness, metallic, transparency values

Example Mapping:

"Warmer tones" + "medium intensity" →
{
  "color_temperature": 4500K,  // Baseline + 1500K shift
  "saturation": 1.2,           // Slight increase
  "ambient_warmth": 0.6        // Add warm ambient light
}

3. Context Manager

Maintains state of current render and conversation history for context-aware suggestions.

Tracked State:

  • Current parameter values
  • Previous user requests (conversation history)
  • Render history for comparison ("go back to the previous version")
  • User preferences learned over time

Context-Aware Features:

  • "Make it warmer" → Interprets based on current color temperature
  • "Reset" → Returns to initial state or specified checkpoint
  • "Like before" → References previous render state

4. Validation & Feedback System

Ensures generated parameters are valid and safe.

Validation Rules:

  • Parameter value range checking (prevent out-of-bounds values)
  • Dependency validation (some parameters conflict with others)
  • Performance constraints (limit expensive operations)
  • Safety checks (prevent extreme values that crash renderer)

Feedback Loop:

  • Track successful vs failed translations
  • Log user corrections and manual parameter adjustments
  • Use feedback to improve future translations
  • Build user-specific preference profiles

Implementation Details

NLP Integration (OpenAI/Anthropic APIs):

Prompt structure for intent extraction:

system_prompt = """
You are a rendering parameter expert. Convert user requests
into structured rendering parameters.

Current scene state:
- Lighting: {current_lighting}
- Materials: {current_materials}
- Camera: {current_camera}

User request: "{user_input}"

Extract:
1. Intent type (lighting/material/camera/atmosphere)
2. Target element (global or specific object)
3. Modification type (set/increase/decrease/toggle)
4. Intensity (subtle/medium/dramatic)

Output as JSON.
"""

Parameter Mapping Engine:

class ParameterMapper:
    def __init__(self):
        self.param_ranges = self._load_parameter_knowledge_base()
        self.context = RenderContext()

    def map_intent_to_parameters(self, intent: Intent) -> RenderParams:
        """
        Translates semantic intent into concrete API parameters.
        """
        if intent.intent_type == "modify_material":
            return self._map_material_modification(intent)
        elif intent.intent_type == "adjust_lighting":
            return self._map_lighting_adjustment(intent)
        # ... other intent types

    def _map_material_modification(self, intent: Intent) -> RenderParams:
        """
        Example: "Warmer tones" → color temperature increase
        """
        current_temp = self.context.get_current_color_temp()

        intensity_multipliers = {
            "subtle": 0.1,
            "medium": 0.3,
            "dramatic": 0.6
        }

        shift = 2000 * intensity_multipliers[intent.intensity]
        new_temp = current_temp + shift

        return RenderParams(
            color_temperature=new_temp,
            saturation=1.0 + (shift / 5000),  # Slight saturation boost
            ambient_warmth=0.3 + (shift / 4000)
        )

FastAPI Endpoint:

from fastapi import FastAPI, HTTPException
from pydantic import BaseModel

app = FastAPI()

class NaturalLanguageRequest(BaseModel):
    user_input: str
    context_id: Optional[str] = None

@app.post("/api/translate")
async def translate_to_parameters(request: NaturalLanguageRequest):
    """
    Translates natural language input to rendering API parameters.
    """
    try:
        # 1. Parse intent using LLM
        intent = await intent_parser.parse(request.user_input)

        # 2. Load context if available
        if request.context_id:
            context = context_manager.get_context(request.context_id)
            parameter_mapper.set_context(context)

        # 3. Map intent to parameters
        params = parameter_mapper.map_intent_to_parameters(intent)

        # 4. Validate parameters
        validated_params = validator.validate(params)

        # 5. Log for feedback loop
        feedback_logger.log_translation(
            user_input=request.user_input,
            intent=intent,
            parameters=validated_params
        )

        return {
            "status": "success",
            "parameters": validated_params.dict(),
            "preview_description": f"Applied {intent.intent_type}: {intent.property}"
        }

    except ValidationError as e:
        raise HTTPException(status_code=400, detail=str(e))
    except Exception as e:
        raise HTTPException(status_code=500, detail="Translation failed")

Challenges & Solutions

Challenge 1: Ambiguous User Input

  • Problem: "Make it better" is too vague to translate
  • Solution: Ask clarifying questions or suggest common improvements based on context

Challenge 2: Conflicting Parameters

  • Problem: Some rendering parameters conflict (e.g., high reflectivity + low lighting = invisible objects)
  • Solution: Dependency graph and automatic parameter adjustment to prevent conflicts

Challenge 3: User Intent Drift

  • Problem: Users reference previous states ("like the last version") without explicit context
  • Solution: Maintain conversation history and render state snapshots for reference

Challenge 4: API Rate Limits (OpenAI/Anthropic)

  • Problem: Every user request calls expensive LLM API
  • Solution: Cache common translations, batch requests, use smaller models for simple queries

Challenge 5: Translation Accuracy

  • Problem: LLM might hallucinate parameters or misinterpret intent
  • Solution: Validation layer, parameter range constraints, user confirmation for dramatic changes

Key Features Implemented

1. Multi-turn Conversations

  • "Add sunset lighting" → "Make it more dramatic" → "Bring back some blue tones"
  • System maintains context across multiple requests

2. Undo/Redo System

  • "Go back to the previous version"
  • "Reset to original"
  • Parameter state snapshots for quick rollback

3. Comparison Mode

  • "Show me before and after"
  • Side-by-side render comparison with parameter diff

4. Smart Suggestions

  • After user applies "sunset lighting," suggest: "Try adding warmer building tones to match"
  • Based on common parameter combinations

5. Preset Commands

  • "Apply morning lighting preset"
  • "Use industrial materials palette"
  • Common configurations saved as reusable presets

Tech Stack

  • NLP Models: GPT-4 (OpenAI), Claude 3 (Anthropic)
  • Backend: Python 3.11, FastAPI, Pydantic
  • Data Storage: Redis (context caching), PostgreSQL (feedback logs)
  • API Client: httpx for async rendering API calls
  • Validation: Custom parameter validation engine with range constraints
  • Monitoring: Logging for translation success rate and user corrections

Performance Metrics

Translation Accuracy:

  • Simple requests (1 parameter): 95% accuracy
  • Medium complexity (2-3 parameters): 85% accuracy
  • Complex requests (4+ parameters): 70% accuracy

Response Time:

  • Intent parsing (LLM call): 500-1500ms
  • Parameter mapping: <50ms
  • Total translation latency: 600-1600ms

API Costs:

  • Average cost per translation: $0.002-0.005 (GPT-4)
  • Optimized with caching: $0.0005-0.001 per request
  • Monthly cost estimate (1000 requests): $1-5

Impact & Learning Outcomes

User Experience Impact:

  • Reduces iteration time from 5-10 minutes (manual parameter tuning) to <1 minute
  • Enables non-technical users to create high-quality renders
  • Lowers barrier to entry for architectural visualization

Technical Skills Demonstrated:

  • Prompt engineering for production applications
  • LLM API integration and optimization
  • Semantic intent parsing and parameter mapping
  • API design for real-time user interactions
  • Error handling and validation strategies

Applicable to ConTech: This natural language interface pattern is highly relevant to construction tech:

  • RFI Management: "Show me all RFIs from last week that are still open"
  • Submittal Search: "Find submittals related to electrical work on floor 3"
  • Schedule Queries: "What's delayed and blocking concrete work?"
  • Document Search: "Pull up the latest HVAC drawings for Zone A"

Construction teams need tools that understand intent rather than requiring technical query syntax. This project demonstrates the ability to build such interfaces.

Future Enhancements

1. Multi-modal Input

  • Voice commands for hands-free operation
  • Image upload: "Make it look like this reference photo"
  • Gesture controls for tablet/mobile use

2. Learning User Preferences

  • Track individual user style preferences
  • Personalized parameter mappings based on user history
  • "Make it warmer" means different things to different users

3. Advanced Context Awareness

  • Project-wide style consistency (all renders follow same aesthetic)
  • Building type awareness (commercial vs residential lighting)
  • Time-of-day suggestions based on project context

4. Collaborative Features

  • Team-shared presets and parameter libraries
  • "Apply the same lighting as John used yesterday"
  • Version control for rendering configurations

Conclusion

This project demonstrates that natural language interfaces can dramatically improve technical tool usability. By abstracting complex parameters behind intuitive language, we enable users to focus on creative decisions rather than technical configuration.

The skills and patterns developed here—prompt engineering, semantic parsing, parameter mapping, validation—are directly transferable to construction tech applications where field teams need simplified interfaces to complex systems.