System Requirements Document for cool-gmod

1. Introduction

cool-gmod is a reference-based character-modeling service for creating a 3-D character that is as accurate as possible to the user-supplied T-pose image and ready to import into Garry’s Mod (GMod). The model must have separated fingers and retain the reference’s recognizable appearance: spiky dark hair, a gray graphic hoodie, camo shorts, socks, and sneakers.

The intended audience is the Model Creator producing the character and the Garry’s Mod Player who uses the resulting model in-game.

2. System Overview

The system provides a custom interface for the Model Creator to supply the reference image, create the character model, and package it for GMod. The accepted work includes a character model—not a static prop—with separated fingers and the reference’s specified appearance. The Garry’s Mod Player is the intended recipient and user of the completed import-ready model.

The Model Creator’s project and export work require continuity across visits. The creator establishes or verifies application identity before protected project work. The Landing page remains anonymously accessible; Sign Up and Login provide the specified first-use and returning access paths. Reference Upload, Model Workspace, and GMod Export are protected.

2a. Product Interpretation and Delivery Boundary

The current product boundary is the reference-based creation and GMod packaging workflow. The supplied image is authoritative content for the character’s appearance and T-pose. The system must not treat the image as a request to reproduce a website or its layout.

The Model Creator supplies the reference, creates the model, and exports the packaged result. The Garry’s Mod Player’s accepted role is to use the completed model in GMod; the player’s observable outcome is that the imported character appears as a usable in-game character model. The system’s export responsibility ends with providing a GMod-importable package. In-game use occurs in Garry’s Mod, outside the custom interface.

Application identity is required only to preserve the creator’s durable project and export work. No differentiated permissions or role-based visibility over shared product state are specified. No additional account-management, modeling, or game-management capabilities are included.

2c. Page Content and Component Coverage

Landing

• Information and state: Anonymous entry explaining the reference-based character-modeling service and its GMod purpose.
• Primary action: Begin by supplying the character reference.
• Supporting actions: Navigate to Sign Up or Login.
• Entities: Character reference; GMod character-modeling purpose.
• Components: Public entry content and clear links to the identity and reference-submission paths.
• States: Loading presents the entry content when available; empty state is the initial public entry; success is navigation to the selected next step; errors in navigation or content loading are communicated with a retry path.

Sign Up

• Information and state: First-use identity establishment for the Model Creator.
• Primary action: Enroll to establish access before protected project work.
• Supporting actions: Continue to Login if the creator already has an identity.
• Entities: Model Creator identity and access state.
• Components: Enrollment interaction and outcome feedback.
• States: Loading indicates enrollment processing; empty state presents the enrollment interaction; success establishes access and continues to Reference Upload; errors explain that enrollment did not complete and allow retry.

Login

• Information and state: Returning verification for the Model Creator’s durable project and export work.
• Primary action: Verify identity to resume protected work.
• Supporting actions: Continue to Sign Up if the creator has not established identity.
• Entities: Model Creator identity, access state, and existing project.
• Components: Verification interaction and outcome feedback.
• States: Loading indicates verification processing; empty state presents the verification interaction; success restores access and continues to the creator’s project work; errors explain that verification did not complete and allow retry.

Reference Upload

• Information and state: The supplied T-pose character reference needed to begin modeling.
• Primary action: Provide the reference image.
• Supporting actions: Review the submitted reference and continue to Model Workspace.
• Entities: Reference image and character project.
• Components: Image submission, reference preview, and continuation control.
• States: Loading indicates image processing; empty state requests the required reference; success confirms the reference is available for modeling; errors identify an unsuccessful submission and allow the creator to retry. Protected access requires verified creator identity.

Model Workspace

• Information and state: The character model and its progress toward matching the reference.
• Primary actions: Create and refine the 3-D character geometry to match the T-pose reference as accurately as possible; keep the fingers separated; reproduce spiky dark hair, a gray graphic hoodie, camo shorts, socks, and sneakers.
• Supporting actions: Inspect the model and its rendered views; continue to GMod Export when the model is complete.
• Entities: Character project, reference image, 3-D character model, separated fingers, and specified appearance details.
• Components: Model work area, reference context, model-view presentation, and completion/continuation state.
• States: Loading indicates project or model work is being prepared; empty state indicates modeling has not yet produced a model; success presents the completed character for export; errors communicate unavailable or unsuccessful model work and preserve a path to resume or retry. Protected access requires verified creator identity.

GMod Export

• Information and state: The completed character model and its GMod-importable package status.
• Primary action: Package and export the completed model in a form ready to import into Garry’s Mod.
• Supporting actions: Review whether packaging completed and provide the resulting package to the Garry’s Mod Player for use.
• Entities: Completed character model, GMod-importable package, and recipient player.
• Components: Export action, packaging status, completion result, and package handoff.
• States: Loading indicates packaging in progress; empty state indicates no completed model is available to package; success confirms the import-ready package is available to the creator and can be used by the player; errors communicate packaging failure and allow the creator to retry or return to Model Workspace. Protected access requires verified creator identity.

3. Functional Requirements

1. As a Model Creator, I should be able to establish access before protected project work.

   • Provenance: required_inference
   • Trigger/input: From the anonymous Landing page, the creator chooses Sign Up and completes the enrollment interaction.
   • Observable result: The creator’s identity is established and access continues to Reference Upload.
   • Access: Sign Up is anonymously reachable; protected project work requires verified identity.
   • Failure/recovery: If enrollment fails, the system communicates the failure and permits retry.
   • Continuation: The creator proceeds to provide the reference image.

2. As a Model Creator, I should be able to verify my identity when returning to protected project work.

   • Provenance: required_inference
   • Trigger/input: From the anonymous Landing page, the returning creator chooses Login and completes verification.
   • Observable result: The creator regains access to their durable project and export work.
   • Access: Login is anonymously reachable; protected project work requires verified identity.
   • Failure/recovery: If verification fails, the system communicates the failure and permits retry.
   • Continuation: The creator resumes project work, including reference, model, or export work as applicable.

3. As a Model Creator, I should be able to provide the T-pose reference image before modeling begins.

   • Provenance: required_inference
   • Trigger/input: The verified creator submits the supplied character reference image through Reference Upload.
   • Observable result: The reference is available to guide creation of the character model.
   • Access: Verified creator identity is required.
   • Failure/recovery: If the image cannot be submitted or processed, the system communicates the failure and allows resubmission.
   • Continuation: The creator proceeds to Model Workspace.

4. As a Model Creator, I should be able to create a 3-D character model based on the supplied T-pose reference image, as accurate as possible to that reference.

   • Provenance: explicit
   • Trigger/input: The creator uses the supplied reference in Model Workspace to create and refine the character.
   • Observable result: A 3-D character model represents the reference’s T-pose and appearance as accurately as possible.
   • Required reference details: Spiky dark hair, gray graphic hoodie, camo shorts, socks, and sneakers.
   • Access: Verified creator identity is required.
   • Failure/recovery: If model work fails or is unavailable, the system communicates the failure and preserves a way to resume or retry.
   • Continuation: The creator continues refining the model or proceeds to GMod Export when complete.

5. As a Model Creator, I should be able to produce a character model with separated fingers.

   • Provenance: explicit
   • Trigger/input: The creator creates and refines the hands in Model Workspace.
   • Observable result: The character model’s fingers are separated rather than represented as a single undivided hand shape.
   • Access: Verified creator identity is required.
   • Failure/recovery: If the model does not preserve separated fingers, the creator can continue refining the model; model-work errors are communicated with a resume or retry path.
   • Continuation: The separated-finger character remains part of the model prepared for export.

6. As a Model Creator, I should be able to package the completed character model in a form ready to import into Garry’s Mod.

   • Provenance: explicit for GMod import readiness; required_inference for packaging as the necessary delivery step.
   • Trigger/input: The creator initiates export from GMod Export after completing the model.
   • Observable result: A GMod-importable package is made available to the creator.
   • Access: Verified creator identity is required.
   • Failure/recovery: If packaging fails, the system communicates the failure and allows retry or return to Model Workspace.
   • Continuation: The creator provides the package to the Garry’s Mod Player for use.

7. As a Garry’s Mod Player, I should be able to use the completed, imported character model in Garry’s Mod.
   • Provenance: required_inference
   • Trigger/input: The player receives and imports the package produced by the creator into Garry’s Mod.
   • Observable result: The character appears as a usable in-game character model.
   • Access: This use occurs in Garry’s Mod, outside the custom interface; no application identity is specified for the player.
   • Failure/recovery: If the package is not import-ready or the character does not appear as usable, the creator can return to GMod Export or Model Workspace to address the package or model and provide an updated package.
   • Continuation: The player uses the imported character in GMod.

4. User Personas

Model Creator

• Provenance: required_inference; the accepted active human persona responsible for the user-requested modeling and export work.
• Product context: Creates a character from the supplied T-pose reference and needs the result prepared for Garry’s Mod.
• Primary goal: Produce a character model that is as accurate as possible to the reference, has separated fingers, and is ready to import into GMod.
• Distinct responsibilities: Establish or verify access, provide the reference image, create and refine the character model and its specified appearance, and package the completed model for GMod.
• Relevant inputs and decisions: Supplies the reference image and determines when model work is ready to export.
• Interaction with the other persona: Provides the import-ready package to the Garry’s Mod Player.
• Observable success: The completed character matches the reference as closely as possible, has separated fingers, and is available in a GMod-importable package.

Garry’s Mod Player

• Provenance: required_inference; the accepted active human persona implied by the stated in-game use of the model.
• Product context: Uses the completed character model in Garry’s Mod after receiving and importing the package.
• Primary goal: Have the imported character appear as a usable in-game character model.
• Distinct responsibilities: Receive and import the creator’s package into Garry’s Mod, then observe whether the character is usable in-game.
• Relevant inputs and decisions: Uses the provided package in GMod and observes the resulting character.
• Interaction with the other persona: Receives the package from the Model Creator; if it is not usable, the creator addresses the model or package and provides an updated result.
• Observable success: The character appears as a usable in-game model.

5. Core User Flows

1. First-time Model Creator: establish access and provide the reference

1. The creator opens Landing anonymously and sees that the service creates a reference-based character model for GMod.
2. The creator chooses Sign Up and completes the enrollment interaction.
3. On successful enrollment, the creator proceeds to Reference Upload with protected access.
4. The creator provides the T-pose reference image.
5. The system confirms that the reference is available for modeling and the creator continues to Model Workspace.
6. If enrollment or image submission fails, the system communicates the failure and offers retry; the creator retries before continuing.

2. Returning Model Creator: verify access and resume work

1. The creator opens Landing and chooses Login.
2. The creator completes verification on Login.
3. On success, the creator regains access to their durable project and continues at the relevant protected work destination.
4. If verification fails, the system communicates the failure and allows retry; the creator retries before resuming protected work.

3. Model Creator: create and refine the character

1. The verified creator opens Model Workspace with the supplied T-pose reference available.
2. The creator creates and refines a 3-D character model to match the reference as accurately as possible.
3. The creator reproduces the reference’s spiky dark hair, gray graphic hoodie, camo shorts, socks, and sneakers.
4. The creator ensures the model has separated fingers.
5. The creator inspects the resulting character and continues refining it as needed.
6. When the model is complete, the creator proceeds to GMod Export. If model work fails or is unavailable, the system communicates the failure and the creator resumes or retries the work.

4. Model Creator: package and hand off the GMod model

1. The verified creator opens GMod Export after completing the character in Model Workspace.
2. The creator initiates packaging for Garry’s Mod.
3. The system reports packaging progress and, on success, makes the GMod-importable package available.
4. If packaging fails, the system communicates the failure; the creator retries or returns to Model Workspace before trying again.
5. The creator provides the completed package to the Garry’s Mod Player.

5. Garry’s Mod Player: import and use the character

1. The player receives the package from the Model Creator.
2. The player imports it into Garry’s Mod.
3. The player observes whether the character appears as a usable in-game character model.
4. If the character is not usable, the player’s outcome is unsuccessful; the creator can address the model or package in Model Workspace or GMod Export and provide an updated package.
5. When the character appears as usable, the player uses it in GMod.

6. Visuals Colors and Theme

The authoritative creative direction is Typography as architecture, after Paula Scher. The interface should feel like a loud, hands-on modding workshop poster rather than a corporate console. The supplied character reference and rendered model views are the product imagery; do not introduce stock people or decorative illustrations.

• Palette: Dark background #111110; surface #1C1B19; primary vermilion #E8442E; acid-yellow accent #F2C230; small teal accent #1F7A6B; paper-white text and rules #F4F1E8; muted text #8F8A7E. No blue or gradients. Use flat, hard-edged color blocks and no more than three flat color blocks in a viewport.
• Typography: Anton for uppercase display headings, never below 28px; Oswald for body, labels, and captions. Display scale clamp(56px, 12vw, 176px); h2 clamp(36px, 6vw, 84px); h3 clamp(24px, 3.4vw, 44px); labels 13px uppercase Oswald 600 with 0.14em letter spacing; body 17px Oswald 300/400 with 1.55 line height; captions 14px Oswald 400 in muted color. Display leading is 0.88 with slight negative tracking.
• Shape and rules: Hard edges; zero border radius on cards, buttons, inputs, and image frames. Use 2px paper-white or black rules. No soft shadows, blur, glass panels, or hover-lift cards.
• Layout: Use a 12-column poster grid with visible hairline column rules, deliberately broken by oversized headlines, color blocks, and rotated vertical bands. At 375px, collapse to one column and scale display type to its clamp minimum. At 375px, 768px, and 1280px, all readable text and controls must remain fully visible and unobstructed; wrap or scale them as needed.
• Imagery: Use the user’s reference image and rendered turntable frames of the character model, hard-cropped inside flat color blocks with a 2px paper rule. Small high-contrast model cutouts may show the separated-finger rig and hoodie graphic. Do not use stock people, decorative illustration, floating rounded cards, or shadows.
• Responsive and motion-related visual constraints: Decorative imagery and shapes may bleed, rotate, or crop as directed, but must not cover readable text or controls. Moving content must allow every item to become fully readable as it passes; with reduced motion, use static wrapped rows or horizontal scrolling so each item can be brought fully into view.

7. Signature Design Concept

Build the public Landing entry as a full-bleed black poster. Set “GMod” in oversized Anton, knocked out in paper white across a vermilion block that bleeds off the left and bottom edges. Place “CHARACTER” as a second acid-yellow line crossing onto the black ground. A rotated vertical band at the right carries “T-POSE → SEPARATED FINGERS → GMod READY.” Pin a hard-edged paper-white UPLOAD REFERENCE CTA beneath the vermilion block, fully inside the viewport at 375px, 768px, and 1280px.

Typography is the hero image. Keep the composition to the accepted GMod character-modeling purpose and reference workflow; do not add behavior, pages, or destinations. The reference image may appear only in the image treatment specified by the creative direction, not as an unrelated decorative asset.

8. Interaction Model & Motion Direction

Interaction Model: Animated
Motion Tempo: expressive
Hero Dimensionality: flat

Landing Hero Motion Brief

• Focal subject: The oversized “GMod” and “CHARACTER” typography, with the reference-based character-modeling purpose expressed through the poster composition.
• Input → transformation → outcome thesis: The creator chooses to upload the reference → the accepted modeling workflow turns that reference into a character with separated fingers → the completed character is packaged for GMod.
• Motion vocabulary: Staggered word reveals rising from behind a color block, with a 120ms stagger and 400ms per word, without bounce. A thin bottom-edge ticker carries the build-state phrases “REFERENCE UPLOADED — MESH BUILDING — FINGERS SEPARATED — GMod READY.” No parallax, blur, or easing theatrics.
• Composed first frame: Full-bleed black poster ground; vermilion block on the left two-thirds; paper-white “GMod” across the block; acid-yellow “CHARACTER” crossing onto the black ground; rotated right-edge pipeline band; paper-white UPLOAD REFERENCE CTA beneath the block.
• Reduced-motion state: Make reveals instant and replace marquees with static wrapped rows. Ensure all ticker items can be read; horizontal scrolling is acceptable if needed to bring each item fully into view.

9. Non-Functional Requirements

1. Responsive readability

   • Provenance: Explicit creative-direction constraint.
   • At 375px, 768px, and 1280px, readable text, labels, numbers, and controls must remain fully inside the viewport and their containers, with no overlap or obstruction. At 375px, use a one-column layout and scale display type to its clamp minimum.

2. Reduced-motion usability

   • Provenance: Explicit creative-direction constraint.
   • With prefers-reduced-motion, make reveals instant and marquees static wrapped rows or horizontally scrollable so every item can be brought fully into view.

3. Visual treatment

   • Provenance: Explicit creative direction.
   • Use flat color blocks, hard edges, and the specified palette and typography. Do not use blue, gradients, rounded corners, soft shadows, glass panels, hover-lift cards, blur, particle effects, decorative 3-D blobs, or decorative illustration.

4. Reference fidelity

   • Provenance: Explicit user requirement and authoritative image directive.
   • The character model must be based on the supplied T-pose reference and be as accurate as possible to it, including separated fingers and the specified appearance details.

10. Tech Stack

• Frontend: [Default — not specified by user] React for the custom interface.
• Backend: [Default — not specified by user] Python/FastAPI to support durable creator project work and model packaging.
• Storage: [Default — not specified by user] Persistent storage for the creator’s project and reference image; file storage for model and export artifacts.
• Deployment: [Default — not specified by user] Docker/docker-compose for deployment.
• No source-specified modeling engine, file format, or GMod packaging technology is established; do not treat a particular choice as a user requirement.

11. Assumptions and Constraints

• Required inference: The creator must provide the reference image before modeling can begin.
• Required inference: The creator must establish or verify application identity before protected project work and export so durable creator-specific work can be resumed.
• Required inference: The completed model must be packaged in a GMod-importable form before the Garry’s Mod Player can use it.
• Explicit constraint: The result is a 3-D character model, not a static prop.
• Explicit constraint: The model must have separated fingers.
• Explicit constraint: The target game is Garry’s Mod.
• The supplied image is authoritative for the character reference. Its visible details include spiky dark hair, a gray graphic hoodie, camo shorts, socks, and sneakers.
• The user’s request is for a model ready to import into GMod; no specific model file format, rig specification, or packaging implementation is stated.
• The Garry’s Mod Player’s in-game use occurs in GMod, outside the custom interface.
• No future requirements are specified.

12. Glossary

• Garry’s Mod (GMod): The game identified by the user as the target for the character model.
• T-pose reference: The supplied image showing the character standing with arms extended, used as the basis for the model.
• Separated fingers: Fingers represented distinctly in the character model rather than as one undivided hand shape.
• GMod-importable package: The completed model packaged in a form ready to import into Garry’s Mod.