The significance of this change lies in making color an integral part of the event categorization structure rather than an independent, manually selected attribute.

With the implementation of this feature, admins will select the corresponding color from a predefined list when creating or editing an event. The ability to create a new color for each individual event will be removed. Once the colors, titles, and dedicated codes have been defined, the collection will be integrated into the administration panel, and the selection and display processes will be reviewed and tested.

The expected outcome is a consistent display of events within the same category using a fixed, recognizable color, alongside a simpler and more organized event management process in Metarang.

یکپارچه‌سازی رنگ رویدادها در متارنگ؛ هر رویداد با هویت بصری مشخص

https://metarang.com/fa/news/categories/technology-and-infrastructure-development/news_10026

A beachfront recreational complex becomes a cohesive architectural design when its different spaces not only serve independent functions but also maintain harmony in their layout, visual identity, and spatial relationships. Metarang’s 24th prompt-writing challenge, focused on designing a modern beach club on Ariana Island, explores precisely this concept.

In this challenge, participants are invited to use artificial intelligence and innovative architectural ideas to design a complex with a proposed area of 2,000 to 3,000 square meters, incorporating three primary functions: celebrations and music, hospitality and relaxation, and swimming and daytime recreation.

1. Functional Zoning

Celebration, Music, and Dance Area

This zone is designed for celebrations, music events, and group gatherings. Suggested elements include an open-air dance and gathering area, a DJ platform, sound equipment, dynamic lighting, laser and fog effects, and suitable canopies for equipment protection.

The design should create a lively and energetic atmosphere for nighttime activities.

Bar, Hospitality, and Relaxation Area

The second function is dedicated to social interaction and hospitality. Key elements include a distinctive central bar, group and couple seating, comfortable furniture, pavilions, semi-covered canopies, and hospitality service facilities.

The connection between this zone, the celebration area, and the swimming pool is an important consideration in coordinating the overall complex.

Swimming Pool and Daytime Recreation

The third zone establishes the beach club’s daytime identity. Suggested features include an outdoor swimming pool overlooking the beach, the possibility of incorporating an infinity pool, sun loungers, comfortable outdoor furniture, lightweight shade structures, and access routes connecting the pool, beach, and other spaces.

2. Architectural Cohesion Across the Three Zones

The three main zones must not be presented as independent or unrelated designs. Consistency in architectural form, materials, color palette, and visual identity must be maintained throughout the complex.

Participants have the freedom to select their architectural concept, structural forms, roof and canopy designs, materials, colors, furniture, landscaping, and lighting. Glass, metal, wood, stone, concrete, and innovative materials may all be incorporated according to the design concept.

However, open spaces, beachfront terraces, and lightweight structures are prioritized. The design should avoid unnecessary complexity and functions while considering spatial dimensions, circulation routes, and how each area will be used.

3. The Importance of the Comprehensive Aerial View in Design Evaluation

One of the challenge’s key requirements is the submission of a fourth image showing a comprehensive aerial or elevated three-quarter view.

This image must present all three main zones together and clearly illustrate:

• The coordinated layout of the three areas.
• Spatial relationships between the celebration, hospitality, and swimming pool zones.
• Access routes and connections to the beach and sea.
• Consistency in architectural form, materials, colors, and visual identity.

The comprehensive view must extend and complete the first three images. Therefore, presenting a different or unrelated design in the fourth image is not acceptable.

4. Final Output Structure

The expected submission consists of four architectural images:

• Image 1: Celebration, music, DJ, and dance area.
• Image 2: Bar, hospitality, and relaxation area.
• Image 3: Swimming pool and daytime recreation beside the sea.
• Image 4: Comprehensive aerial view of the complex, showing the layout of all three zones.

The objective of this challenge is to create an integrated, functional, and creative beachfront complex that offers a relaxing atmosphere during the day and a vibrant environment for entertainment and social interaction at night.

To submit your images and participate in Metarang’s 24th prompt-writing challenge, join the Bale channel:

http://ble.ir/meta_rang

#متارنگ #معماری_دیجیتال #طراحی_فضایی

در این چالش، شرکت‌کنندگان باید با بهره‌گیری از هوش مصنوعی و ایده‌های معماری نوآورانه، مجموعه‌ای با مساحت پیشنهادی ۲۰۰۰ تا ۳۰۰۰ مترمربع طراحی کنند که سه کاربری اصلی جشن و موسیقی، پذیرایی و استراحت، و استخر و تفریحات روزانه را در بر بگیرد.

۱. تفکیک عملکردی فضاها

فضای جشن، موسیقی و رقص

این بخش برای برگزاری جشن‌ها، رویدادهای موسیقی و گردهمایی‌های گروهی طراحی می‌شود. فضای روباز رقص و تجمع مهمانان، سکوی DJ، تجهیزات صوتی، نورپردازی متحرک، افکت‌های لیزری و مه و سایه‌بان مناسب تجهیزات، عناصر پیشنهادی آن هستند.

طراحی این قسمت باید امکان شکل‌گیری فضایی زنده و پرانرژی در شب را فراهم کند.

بار، پذیرایی و فضای استراحت

کاربری دوم، فضای اجتماعی و پذیرایی مجموعه است. بار مرکزی با معماری شاخص، نشیمن‌های گروهی و دونفره، مبلمان راحت، پاویون‌ها، سایه‌بان‌های نیمه‌مسقف و فضای خدماتی پذیرایی از عناصر مورد توجه این بخش محسوب می‌شوند.

ارتباط این قسمت با فضای جشن و محدوده استخر، یکی از نکات مهم در هماهنگی کل مجموعه است.

استخر و تفریحات روزانه

بخش سوم، هویت روزانه کلاب را شکل می‌دهد. استخر روباز با چشم‌انداز ساحلی، امکان استفاده از فرم اینفینیتی پول، تخت‌های آفتاب‌گیری، مبلمان راحتی، سایه‌بان‌های سبک و مسیرهای دسترسی میان استخر، ساحل و سایر فضاها، از موارد پیشنهادی طراحی هستند.

۲. انسجام معماری میان سه بخش

سه بخش اصلی نباید به‌صورت طرح‌هایی مستقل و نامرتبط ارائه شوند. هماهنگی فرم معماری، متریال، رنگ‌بندی و هویت بصری باید در تمامی قسمت‌ها حفظ شود.

در انتخاب کانسپت معماری، فرم سازه‌ها، نوع سقف و سایه‌بان، متریال، رنگ‌بندی، مبلمان، پوشش گیاهی و نورپردازی، آزادی عمل برای شرکت‌کنندگان وجود دارد. استفاده از شیشه، فلز، چوب، سنگ، بتن یا متریال‌های نوآورانه متناسب با ایده طراحی امکان‌پذیر است.

با این حال، اولویت با فضاهای روباز، تراس‌های ساحلی و سازه‌های سبک است. طراحی باید از شلوغی و کاربری‌های غیرضروری پرهیز کند و به ابعاد، مسیرهای رفت‌وآمد و نحوه استفاده از فضاها توجه داشته باشد.

۳. اهمیت نمای جامع هوایی در ارزیابی طرح

یکی از الزامات مهم چالش، ارائه تصویر چهارم به‌عنوان نمای جامع هوایی یا سه‌ربع از بالا است.

این تصویر باید سه بخش اصلی را در کنار یکدیگر نمایش دهد و موارد زیر را به‌روشنی مشخص کند:

جانمایی هماهنگ سه بخش مجموعه.

ارتباط فضایی میان فضاهای جشن، پذیرایی و استخر.

مسیرهای دسترسی و ارتباط با ساحل و دریا.

هماهنگی فرم معماری، متریال، رنگ و هویت بصری.

نمای جامع باید ادامه و تکمیل سه تصویر نخست باشد؛ بنابراین، ارائه طرحی متفاوت یا نامرتبط در تصویر چهارم قابل قبول نیست.

۴. ساختار خروجی نهایی

خروجی مورد انتظار شامل چهار تصویر معماری است:

تصویر اول: فضای جشن، موسیقی، DJ و رقص.

تصویر دوم: بار، پذیرایی و فضای استراحت.

تصویر سوم: استخر و تفریحات روزانه در مجاورت دریا.

تصویر چهارم: نمای جامع هوایی مجموعه و جانمایی سه بخش.

هدف این چالش، خلق مجموعه‌ای ساحلی، یکپارچه، کاربردی و خلاقانه است که در روز فضایی آرامش‌بخش و در شب محیطی پرنشاط برای سرگرمی و تعاملات اجتماعی فراهم کند.

برای ارسال تصاویر و شرکت در بیست‌وچهارمین چالش پرامپت‌نویسی متارنگ، در کانال بله عضو شوید:

http://ble.ir/meta_rang

#متارنگ #معماری_دیجیتال #طراحی_فضایی

An examination of the engineering layers behind virtual property — from defining spatial boundaries and coordinates to asset identification, ownership registration, 3D model standardization, and graphics resource management.

Introduction: What Exactly Is a Digital Property Made Of?

When we talk about virtual property, we usually imagine a plot of land in a three-dimensional environment — a defined area where buildings can be constructed, users can move around, and activities can take shape.

However, from the perspective of software engineering and 3D systems, a digital property is much more than a graphical surface.

Defining such an asset requires solving several independent but interconnected problems: How are its spatial boundaries established? Which coordinate system defines its position? How is it distinguished from other plots? Where is its ownership information stored? How is a building’s 3D model introduced into the runtime environment? And how does the graphics engine process and display this data?

These questions show that the architecture of digital real estate depends on a combination of geometry engineering, data management, ownership system design, 3D model exchange standards, and rendering technologies.

To examine this architecture, a virtual property can be understood as a collection of independent layers, each with a specific responsibility and connected to the others through identifiers and data contracts.

1. Defining a Spatial Asset in a Digital Environment

The first step in creating a virtual property is defining it as a Spatial Asset.

A spatial asset is an area within a digital environment that has identifiable location, dimensions, and geometric characteristics. This definition is fundamentally different from a simple graphical model: a graphical model describes only an object’s appearance, whereas a spatial asset must also provide the system with the information needed to identify and manage its boundaries.

For example, imagine a collection of commercial plots positioned next to one another in a virtual environment. Each plot must be independently identifiable, even if several plots are displayed within the same 3D scene.

Several concepts are important in this structure:

• Asset ID: A unique identifier used to reference each property within the system.
• Spatial Boundary: The geometric boundary that defines the property’s area.
• Position: The property’s location within the environment’s coordinate system.
• Geometric Properties: Information such as area, dimensions, permitted height, or density-related specifications.
• Metadata: Descriptive and management information associated with the asset.

These pieces of information should not be confused with one another. For example, a property’s identifier establishes its logical identity, while its coordinates define its spatial position.

Likewise, displaying a property in the user interface should not be the only source of its identity information. The appearance of a plot on a map may change, but its identifier and core specifications should remain independently retrievable.

From this perspective, the first principle of digital real estate architecture is to separate asset-descriptive data from the graphical presentation layer.

2. Geometric Modeling of Land

After defining the spatial asset, its geometric boundaries must be established. This is one of the foundations of digital real estate architecture because every subsequent operation — from calculating area to controlling construction — depends on the accuracy of the land’s geometry.

2.1. Representing Land with Polygons

One common method for representing the boundaries of a plot of land is to use a polygon.

In this model, the land boundary consists of a set of coordinate points connected to one another in sequence.

If the land boundary is defined by the following points:

[
P_i=(x_i,y_i)
]

The collection of these points forms the plot’s two-dimensional boundary.

The Shoelace formula can be used to calculate the area of a simple polygon in a Cartesian coordinate system:

[
A=\frac{1}{2}\left|
\sum_{i=1}^{n}
(x_i y_{i+1}-x_{i+1}y_i)
\right|
]

In this relationship, the final point is connected to the first point; therefore:

[
P_{n+1}=P_1
]

This formula makes it possible to calculate a plot’s geometric area from the coordinates of its boundaries.

However, in a real system, area calculation also depends on the choice of coordinate system. If coordinates are based on latitude and longitude, they cannot be used directly as metric Cartesian coordinates in this formula without conversion or an appropriate geodesic geometry method.

2.2. Coordinate Systems and Positional Consistency

In a three-dimensional environment, coordinates are generally defined using three components:

[
P=(x,y,z)
]

In this structure, X and Y define the horizontal position, while Z represents elevation.

Choosing an appropriate coordinate system is essential. For example, if a plot of land is defined on a map using local coordinates, all buildings and components placed on it must use a compatible spatial reference.

Otherwise, a building model may not align with the land when imported into the runtime environment, or it may appear displaced from its expected position.

In technical architecture, using a shared Coordinate Reference System (CRS) and defining a specific Origin helps maintain consistency between geometric data.

2.3. Three-Dimensional Structures and the Concept of Voxels

Polygons are suitable for defining the surface boundaries of land, but they are not always sufficient for describing the volumetric structure of an environment.

In volumetric models, the concept of a Voxel becomes relevant. A voxel can be considered the three-dimensional equivalent of a pixel: a volumetric unit positioned within a three-dimensional grid.

In this type of model, an environment can be represented as a collection of volumetric cells. This approach is useful in certain applications, including volumetric environment representation, simulation, and spatial analysis.

However, Polygon and Voxel are two different methods of representing geometry and should not be treated as direct substitutes for one another.

For defining land boundaries, polygons are generally an appropriate structure, while volumetric representations can be used to describe parts of an environment or three-dimensional structures.

2.4. Geometry Validation

Defining coordinates alone is not enough. The geometry of each plot must also be checked for consistency.

Some important validation checks include:

• Ensuring that the boundary forms a Closed Ring.
• Preventing invalid edge intersections (Self-Intersection).
• Checking for unintended overlaps between plots.
• Verifying that the plot lies within the permitted map boundaries.
• Validating area and dimensions.
• Checking geometric consistency with density and construction rules.

These checks help prevent errors that could cause problems in later stages, such as building construction or calculating ownership boundaries.

Therefore, land geometry is not merely data used to render a map; it is one of the primary sources of validation in a digital real estate system.

3. Digital Identification and Ownership Architecture

After defining the geometry, the next step is to connect the asset to its ownership information.

This layer should remain separate from the geometric layer. Geometry determines where a property is located and what area it covers, while the ownership layer establishes who is recognized as its owner within the system.

3.1. Asset Identification and Virtual Ownership Documents

In digital real estate architecture, a unique identifier can serve as the connection point between different sets of property information.

For example, geometric data, ownership status, transfer history, and management specifications can all be linked through an Asset ID.

In Rang Metaverse, the concept of VOD (Virtual Ownership Document) is introduced for identifying and registering virtual asset ownership.

At a conceptual level, VOD can be understood as a document associated with an asset’s identity and its ownership information within the system.

To analyze this concept technically, several types of data must be distinguished:

1. Property identity information;
2. Geometric and spatial information;
3. Current owner information;
4. Ownership transfer history;
5. A reference to the corresponding asset or identifier within the registration infrastructure.

Separating these types of information allows the system to manage property data without becoming entirely dependent on a single layer.

3.2. The Role of Blockchain in Transaction Records

Blockchain is a distributed data-recording structure in which transaction information is recorded in blocks according to the network’s validation rules.

In a digital ownership architecture, blockchain can be used to record events such as asset creation, ownership transfers, and changes in asset status.

An important distinction must be made between On-chain and Off-chain data.

Storing all geometric information and 3D models on a blockchain is generally not an appropriate choice, because these datasets can be large and their storage and processing costs may be high.

For this reason, it is possible to separate the information required for ownership verification and tracking from large datasets associated with 3D models.

For example:

• Token identifiers and ownership information can be recorded on the blockchain layer.
• The geometric model of the land can be stored in a spatial database.
• The building’s 3D model can be stored in file storage.
• Connections between these datasets can be maintained through asset identifiers and specific references.

This separation does not mean eliminating the relationships between datasets. It means choosing a storage location appropriate to the nature of each type of data.

3.3. NFTs and the ERC-721 Standard

A Non-Fungible Token (NFT) is a token with a distinct identity that can be used to represent a unique asset.

The ERC-721 standard defines shared rules for creating and managing these tokens on networks compatible with the Ethereum Virtual Machine.

In a conceptual digital real estate model, each plot of land can be represented by a unique token.

In this case, the Token ID makes it possible to identify the token, while a smart contract can manage operations related to ownership and transfer.

The ERC-1155 standard is also designed to manage collections of fungible and non-fungible tokens within a single contract. It can be useful in scenarios involving the management of equipment, items, or multiple types of assets.

However, the choice of standard should be based on the asset model and the system’s requirements. Mentioning a standard in a proposed architecture does not necessarily mean that it is actively implemented in a particular project.

3.4. Smart Contracts and Ownership Transfers

A Smart Contract is a set of executable rules implemented within a blockchain environment.

For example, an NFT-related contract can manage token transfer operations according to the rules of its standard.

However, transferring a token and transferring all rights associated with a digital property are not necessarily the same thing.

To establish a reliable ownership system, several questions must be addressed:

• Which transfer operations are permitted?
• Are there any restrictions or conditions on transfers?
• How is the relationship between the token ID and the property ID maintained?
• If off-chain information changes, how is data consistency verified?
• What mechanisms exist for handling errors or conflicting information?

These questions demonstrate that designing digital ownership is not simply a matter of choosing an NFT standard; it also requires the design of data rules and operational mechanisms.

4. Standards for Three-Dimensional Assets

After defining the land and establishing its ownership structure, the system must support the creation and import of buildings and other three-dimensional components.

At this stage, 3D data exchange standards become important.

A 3D model may be designed in different software applications, but to be used in a runtime environment, its geometry, materials, textures, and other required information must be transferable in a compatible format.

4.1. The OBJ Format

The OBJ format is one of the well-known formats for storing 3D geometry.

It can store information such as:

• Vertex coordinates (Vertices).
• Surface and face information (Faces).
• UV coordinates.
• Normals.

Material information is generally referenced through an accompanying MTL file.

OBJ’s advantages include simplicity and broad support across modeling tools. However, it was not designed for fully managing complex interactive scenes, animation, or advanced asset structures.

4.2. The glTF and GLB Formats

glTF, short for GL Transmission Format, was designed to enable efficient transfer of 3D assets.

This standard can provide geometry, materials, textures, object hierarchies, and — where supported — animation in a structure suitable for use by graphics engines.

Two common forms are:

• glTF: A format that typically consists of a JSON file and external resources such as binary files and images.
• GLB: The binary version of glTF, which allows different parts of an asset to be packaged into a single file.

For example, a building designed in 3D software can be exported as a GLB file and imported into a runtime environment. The graphics engine then processes its geometric and material information.

From this perspective, glTF/GLB play an important role in transferring 3D assets into real-time environments.

4.3. The 3D Tiles Standard

In large-scale environments, managing numerous 3D models and spatial datasets can become a complex task.

The 3D Tiles standard was developed to manage and transmit large-scale 3D and geospatial data.

It enables data to be organized into a hierarchical structure and loaded progressively.

For example, when displaying a large urban environment, there is no need to load every detail of every building at all times. The system can retrieve appropriate data based on the camera’s position and the required level of detail.

This approach is connected to the concept of LOD (Level of Detail).

LOD allows the system to display versions of different geometric complexity depending on the camera’s distance.

As a result, processing requirements are reduced and a more stable visual experience can be achieved.

However, 3D Tiles is not a replacement for formats such as GLB. It serves a different purpose at the level of organizing, distributing, and loading large-scale 3D data.

5. Graphics Engines and Resource Management

Geometric data and 3D models become visible to users when they are processed within a runtime environment.

Game Engines are responsible for this task.

Engines such as Unity provide tools for managing scenes, processing geometry, materials, lighting, cameras, and interactions.

In digital real estate architecture, the graphics engine must be able to receive information about land and buildings, position them correctly, and generate the appropriate image in every frame.

However, this process involves more than simply displaying a model.

5.1. Scene and Transform Management

Every object in a 3D scene has information about its position, rotation, and scale.

This information is generally managed through a Transform:

• Position: The object’s location.
• Rotation: The object’s orientation.
• Scale: The object’s size.

In a digital real estate environment, converting property coordinates into scene coordinates is particularly important.

For example, if a building’s position is stored in a database using a global coordinate system, the graphics engine must convert it into the scene’s local coordinates.

A lack of consistency between these two coordinate systems can cause the model to appear displaced, incorrectly rotated, or improperly scaled.

For this reason, defining a Coordinate Transformation Layer is important.

5.2. Memory and Resource Management

3D models consume processing resources and memory.

A high number of polygons, large textures, complex materials, and interactive objects can place significant pressure on the GPU and CPU.

Some common resource management techniques include:

• LOD: Reducing a model’s geometric complexity according to camera distance.
• Occlusion Culling: Skipping the processing of objects hidden behind other scene elements.
• Frustum Culling: Avoiding the processing of objects outside the camera’s viewing area.
• Texture Compression: Reducing texture sizes to optimize memory usage.
• Batching: Grouping certain rendering operations to reduce processing overhead.
• Asynchronous Loading: Loading assets asynchronously to prevent lengthy interruptions during application execution.

These techniques become increasingly important in large environments, where the number of models and users can grow rapidly.

5.3. Progressive Loading and Large Environment Management

Imagine a virtual city containing thousands of buildings and land plots.

Loading every model as soon as a user enters the environment can increase startup time and memory consumption.

A suitable solution is Progressive Loading.

With this approach, the system initially loads essential data and then retrieves additional resources according to the user’s position, viewing area, and interaction requirements.

In such an architecture, 3D asset management should not take place exclusively within the graphics engine. Storage systems, file distribution, resource caching, and version management also affect overall performance.

Therefore, the execution quality of a virtual real estate environment depends on cooperation between the data layer, storage infrastructure, and graphics engine.

6. From Data to Utilization: Connecting the Architectural Layers

So far, each technical component has been examined independently. However, a digital real estate system takes shape only when these components are connected through an operational workflow.

To clarify their relationships, the conceptual architecture of a digital property can be summarized in six layers:

Layer 1: Spatial Data

Includes coordinates, geometric boundaries, land area, and the property’s spatial specifications.

Layer 2: Asset Identity

Includes Asset ID, metadata, and the connection between the property and its descriptive information.

Layer 3: Ownership and Transactions

Includes VOD, ownership information, token identifiers, and transfer records when blockchain infrastructure is used.

Layer 4: 3D Assets

Includes building models, materials, textures, and standard file formats such as GLB.

Layer 5: Graphics Execution

Includes the rendering engine, scene management, coordinate transformation, loading, and 3D interactions.

Layer 6: Utilization

Includes defining the property’s purpose, creating commercial or service spaces, and enabling users to interact with and use the environment.

The relationship between these layers can be illustrated through a simple workflow:

Spatial Geometry
       |
       v
    Asset ID
       |
       v
  Ownership Layer
  (VOD / Blockchain)
       |
       v
  3D Asset Pipeline
  (OBJ / glTF / GLB)
       |
       v
  Rendering Engine
  (Scene / GPU / LOD)
       |
       v
  Digital Environment
       |
       v
  Commercial Utilization

In this model, the asset identifier serves as the connecting element. Through this identifier, the system can retrieve the land’s geometry, ownership information, and associated 3D model.

For example, when a user selects a commercial plot on a map, the user interface can retrieve its identifier. The system can then retrieve the property’s geometric information and specifications from the data layer and read its ownership information from the relevant infrastructure.

If a building has been defined for that plot, its associated 3D model can also be retrieved from storage and loaded into the graphics engine.

As a result, what users perceive as a single property is, behind the scenes, composed of several independent data types and subsystems.

Practical Example: Commercial Real Estate Architecture in Rang Metaverse

In the article “The Comprehensive Guide to Commercial Real Estate in Rang Metaverse,” these concepts are presented within an operational structure.

Commercial plots in Metarang are defined on the map as distinct geometric parcels. Their location, boundaries, and specifications form the basis for identifying them within the virtual environment.

At the ownership layer, VOD is considered a mechanism for identifying and registering virtual asset ownership. The article also discusses the role of blockchain and standards such as ERC-721 in representing unique assets.

During the development stage, the owner can prepare a 3D model of the intended building and use formats such as OBJ or glTF/GLB to transfer the asset.

Finally, the model is introduced into the 3D environment, making it possible to create commercial, administrative, or service spaces according to the intended use.

This example demonstrates that digital real estate architecture does not depend on a single technology. Instead, it emerges from the interaction between geometry, data identity, ownership, 3D standards, and graphics infrastructure.

It is important to note, however, that introducing a technology or standard as part of a conceptual architecture does not confirm that every component is actively used in the system’s current implementation. A technical assessment of a product also requires examining implementation documentation and the details of each architectural layer.

Conclusion: A Digital Property Is More Than a Simple 3D Model

The technical architecture of digital real estate cannot be reduced to designing a plot of land or creating a three-dimensional building.

To become a manageable asset, a virtual property requires precise geometric definition, a consistent coordinate system, a unique identifier, an ownership registration structure, 3D model exchange standards, and graphics execution infrastructure.

Each of these layers solves a different problem:

• Geometry defines the asset’s boundaries and location.
• An identifier enables independent referencing of the property.
• VOD and ownership infrastructure organize information related to the owner.
• Blockchain and NFTs can support mechanisms for asset registration and transfer.
• 3D standards facilitate the transfer of models between different tools.
• The graphics engine transforms data into a visible and interactive environment.

Ultimately, the engineering value of this architecture lies in separating responsibilities and establishing standardized connections between them.

When geometric data, ownership information, and 3D models are managed independently but consistently, it becomes possible to develop a structured digital environment — one in which land is not merely a graphical element, but an asset with an identity, boundaries, ownership information, and spatial development potential.

The key technical question is this: When designing a metaverse real estate system, which layer should serve as the ultimate source of truth for asset information — the spatial database, the digital ownership document, or the smart contract?

The answer to this question is one of the fundamental decisions in designing the architecture of such a system.

https://metarang.com/fa/articles/categories/algorithms/BL_10043

مقدمه: یک ملک دیجیتال دقیقاً از چه چیزی ساخته می‌شود؟

وقتی درباره یک ملک مجازی صحبت می‌کنیم، معمولاً تصویری از یک قطعه زمین در محیط سه‌بعدی به ذهن می‌رسد؛ محدوده‌ای که می‌توان روی آن ساختمان ساخت، در آن حرکت کرد و فعالیتی را شکل داد.

اما از دیدگاه مهندسی نرم‌افزار و سیستم‌های سه‌بعدی، یک ملک دیجیتال صرفاً یک سطح گرافیکی نیست.

برای تعریف چنین دارایی‌ای باید چند مسئله مستقل اما مرتبط حل شوند: محدوده فضایی آن چگونه مشخص می‌شود؟ مختصات آن در چه دستگاهی تعریف شده‌اند؟ چگونه از سایر قطعات تفکیک می‌شود؟ اطلاعات مالکیت آن کجا نگهداری می‌شوند؟ مدل سه‌بعدی ساختمان چگونه وارد محیط اجرا می‌شود؟ و موتور گرافیکی چگونه این داده‌ها را پردازش و نمایش می‌دهد؟

این پرسش‌ها نشان می‌دهند که معماری املاک دیجیتال به ترکیبی از مهندسی هندسه، مدیریت داده، طراحی سیستم‌های مالکیت، استانداردهای تبادل مدل سه‌بعدی و فناوری رندرینگ وابسته است.

برای بررسی این معماری، می‌توان یک ملک مجازی را به‌عنوان مجموعه‌ای از لایه‌های مستقل در نظر گرفت که هرکدام مسئولیت مشخصی دارند و از طریق شناسه‌ها و قراردادهای داده‌ای با یکدیگر ارتباط برقرار می‌کنند.

۱. تعریف دارایی فضایی در محیط دیجیتال

نخستین مرحله در ایجاد یک ملک مجازی، تعریف آن به‌عنوان یک دارایی فضایی (Spatial Asset) است.

دارایی فضایی به محدوده‌ای از محیط دیجیتال گفته می‌شود که موقعیت، ابعاد و مشخصات هندسی قابل‌شناسایی دارد. این تعریف با یک مدل گرافیکی ساده تفاوت اساسی دارد؛ زیرا مدل گرافیکی تنها ظاهر یک شیء را توصیف می‌کند، درحالی‌که دارایی فضایی باید اطلاعات لازم برای شناسایی و مدیریت محدوده آن را نیز در اختیار سیستم قرار دهد.

برای مثال، تصور کنید در یک محیط مجازی مجموعه‌ای از قطعات تجاری در کنار یکدیگر قرار گرفته‌اند. هر قطعه باید به‌صورت مستقل قابل‌شناسایی باشد؛ حتی اگر چند قطعه در یک صحنه سه‌بعدی مشترک نمایش داده شوند.

در این ساختار، چند مفهوم اهمیت دارند:

شناسه دارایی (Asset ID): شناسه‌ای یکتا برای ارجاع به هر ملک در سیستم.

محدوده فضایی (Spatial Boundary): مرز هندسی تعیین‌کننده محدوده ملک.

موقعیت (Position): محل قرارگیری ملک در دستگاه مختصات محیط.

ویژگی‌های هندسی (Geometric Properties): اطلاعاتی مانند مساحت، ابعاد، ارتفاع مجاز یا مشخصات مرتبط با تراکم.

فراداده (Metadata): اطلاعات توصیفی و مدیریتی مرتبط با دارایی.

این اطلاعات نباید با یکدیگر اشتباه گرفته شوند. برای نمونه، شناسه ملک هویت منطقی آن را مشخص می‌کند، درحالی‌که مختصات، موقعیت فضایی آن را تعریف می‌کنند.

همچنین، نمایش یک ملک در رابط کاربری نباید تنها منبع اطلاعات هویتی آن باشد. ممکن است ظاهر یک قطعه در نقشه تغییر کند، اما شناسه و مشخصات پایه آن باید بتوانند مستقل از نحوه نمایش بازیابی شوند.

از این منظر، نخستین اصل معماری املاک دیجیتال، جداسازی داده‌های توصیف‌کننده دارایی از لایه نمایش گرافیکی است.

۲. مدل‌سازی هندسی زمین

پس از تعریف دارایی فضایی، باید محدوده هندسی آن مشخص شود. این مرحله یکی از پایه‌های اصلی معماری املاک دیجیتال است؛ زیرا هرگونه عملیات بعدی، از محاسبه مساحت تا کنترل ساخت‌وساز، به صحت هندسه زمین وابسته خواهد بود.

۲.۱. نمایش زمین با Polygon

یکی از روش‌های متداول برای نمایش محدوده یک قطعه زمین، استفاده از چندضلعی یا Polygon است.

در این مدل، مرز زمین از مجموعه‌ای از نقاط مختصاتی تشکیل می‌شود که به ترتیب به یکدیگر متصل شده‌اند.

اگر محدوده زمین با نقاط زیر تعریف شود:

[

P_i=(x_i,y_i)

]

مجموعه این نقاط، مرز دوبعدی قطعه را تشکیل می‌دهد.

برای محاسبه مساحت یک چندضلعی ساده در دستگاه مختصات دکارتی می‌توان از فرمول Shoelace استفاده کرد:

[

A=\frac{1}{2}\left|

\sum_{i=1}^{n}

(x_i y_{i+1}-x_{i+1}y_i)

\right|

]

در این رابطه، نقطه پایانی به نقطه ابتدایی متصل می‌شود؛ بنابراین:

[

P_{n+1}=P_1

]

این فرمول امکان محاسبه مساحت هندسی قطعه را از روی مختصات مرزهای آن فراهم می‌کند.

البته در یک سیستم واقعی، محاسبه مساحت به انتخاب دستگاه مختصات نیز وابسته است. اگر مختصات بر مبنای طول و عرض جغرافیایی باشند، نمی‌توان بدون تبدیل یا استفاده از روش‌های مناسب هندسه ژئودزیک، آن‌ها را مستقیماً مانند مختصات متری در فرمول دکارتی به کار برد.

۲.۲. دستگاه مختصات و ثبات موقعیت

در محیط سه‌بعدی، مختصات معمولاً با سه مؤلفه تعریف می‌شوند:

[

P=(x,y,z)

]

در این ساختار، X و Y موقعیت افقی و Z ارتفاع را مشخص می‌کنند.

انتخاب دستگاه مختصات مناسب اهمیت زیادی دارد. برای مثال، اگر یک زمین در نقشه با مختصات محلی تعریف شده باشد، تمام ساختمان‌ها و اجزای قرارگرفته روی آن باید از یک مرجع فضایی سازگار استفاده کنند.

در غیر این صورت، ممکن است مدل ساختمان هنگام ورود به محیط اجرا با زمین هم‌تراز نباشد یا نسبت به موقعیت مورد انتظار جابه‌جا شود.

در معماری فنی، استفاده از یک مرجع مختصات مشترک (Coordinate Reference System) و تعریف مبدأ مشخص (Origin) به هماهنگی داده‌های هندسی کمک می‌کند.

۲.۳. ساختار سه‌بعدی و مفهوم Voxel

Polygon برای تعریف محدوده سطحی زمین مناسب است، اما همیشه برای توصیف ساختار حجمی محیط کافی نیست.

در مدل‌های حجمی، مفهوم Voxel مطرح می‌شود. وکسل را می‌توان معادل سه‌بعدی پیکسل دانست؛ واحدی حجمی که در یک شبکه سه‌بعدی قرار می‌گیرد.

در چنین مدلی، فضای محیط می‌تواند با مجموعه‌ای از سلول‌های حجمی نمایش داده شود. این روش در برخی کاربردها مانند نمایش محیط‌های حجمی، شبیه‌سازی و تحلیل فضایی مفید است.

بااین‌حال، Polygon و Voxel دو روش متفاوت برای نمایش هندسه هستند و نباید آن‌ها را جایگزین مستقیم یکدیگر دانست.

برای تعریف مرز زمین، Polygon معمولاً ساختار مناسبی است؛ درحالی‌که نمایش حجمی می‌تواند برای توصیف بخش‌هایی از محیط یا سازه‌های سه‌بعدی مورد استفاده قرار گیرد.

۲.۴. اعتبارسنجی هندسه

تعریف مختصات به‌تنهایی کافی نیست. هندسه هر قطعه باید از نظر سازگاری نیز بررسی شود.

برخی از کنترل‌های مهم عبارت‌اند از:

بسته‌بودن حلقه مرزی (Closed Ring).

جلوگیری از تقاطع نامعتبر اضلاع (Self-Intersection).

بررسی هم‌پوشانی ناخواسته قطعات.

کنترل قرارگیری قطعه در محدوده مجاز نقشه.

اعتبارسنجی مساحت و ابعاد.

بررسی سازگاری هندسه با قواعد تراکم و ساخت‌وساز.

این کنترل‌ها به جلوگیری از خطاهایی کمک می‌کنند که ممکن است در مراحل بعدی، مانند ساخت ساختمان یا محاسبه محدوده مالکیت، مشکل ایجاد کنند.

بنابراین، هندسه زمین صرفاً یک داده برای رندرکردن نقشه نیست؛ بلکه یکی از منابع اصلی صحت‌سنجی در سیستم املاک دیجیتال محسوب می‌شود.

۳. معماری شناسایی و مالکیت دیجیتال

پس از تعریف هندسه، نوبت به ارتباط‌دادن دارایی با اطلاعات مالکیت می‌رسد.

این بخش باید از لایه هندسی جدا باشد. هندسه مشخص می‌کند ملک کجاست و چه محدوده‌ای دارد؛ اما لایه مالکیت مشخص می‌کند چه کسی در ساختار سامانه به‌عنوان مالک آن شناخته می‌شود.

۳.۱. شناسه دارایی و سند مالکیت مجازی

در معماری املاک دیجیتال، یک شناسه یکتا می‌تواند نقطه اتصال میان اطلاعات مختلف ملک باشد.

برای نمونه، اطلاعات هندسی، وضعیت مالکیت، سوابق انتقال و مشخصات مدیریتی می‌توانند از طریق Asset ID به یکدیگر مرتبط شوند.

در متاورس رنگ، مفهوم VOD یا Virtual Ownership Document برای شناسایی و ثبت مالکیت مجازی دارایی مطرح شده است.

VOD را می‌توان در سطح مفهومی، سندی مرتبط با هویت دارایی و اطلاعات مالکیت آن در ساختار سامانه در نظر گرفت.

برای تحلیل فنی این مفهوم، باید میان چند نوع داده تفاوت قائل شد:

۱. اطلاعات هویتی ملک؛

۲. اطلاعات هندسی و مکانی؛

۳. اطلاعات مالک فعلی؛

۴. سوابق مربوط به انتقال مالکیت؛

۵. ارجاع به دارایی یا شناسه متناظر در زیرساخت ثبت.

تفکیک این اطلاعات به سیستم اجازه می‌دهد بدون وابستگی کامل به یک لایه، داده‌های مربوط به ملک را مدیریت کند.

۳.۲. نقش Blockchain در ثبت تراکنش‌ها

بلاکچین (Blockchain) یک ساختار ثبت داده توزیع‌شده است که در آن اطلاعات تراکنش‌ها در قالب بلوک‌ها و بر اساس قواعد اعتبارسنجی شبکه ثبت می‌شوند.

در یک معماری مالکیت دیجیتال، بلاکچین می‌تواند برای ثبت رویدادهایی مانند ایجاد دارایی، انتقال مالکیت و تغییر وضعیت آن مورد استفاده قرار گیرد.

نکته مهم، تفاوت میان داده‌های روی زنجیره (On-chain) و خارج از زنجیره (Off-chain) است.

نگهداری تمام اطلاعات هندسی و مدل‌های سه‌بعدی روی بلاکچین معمولاً انتخاب مناسبی نیست؛ زیرا این داده‌ها ممکن است حجم زیادی داشته باشند و هزینه ذخیره‌سازی و پردازش آن‌ها بالا باشد.

به همین دلیل، می‌توان میان اطلاعات ضروری برای اثبات و رهگیری مالکیت و داده‌های حجیم مربوط به مدل سه‌بعدی تفکیک ایجاد کرد.

برای مثال:

شناسه توکن و اطلاعات مالکیت می‌توانند در لایه بلاکچین ثبت شوند.

مدل هندسی زمین می‌تواند در پایگاه داده مکانی نگهداری شود.

مدل سه‌بعدی ساختمان می‌تواند در فضای ذخیره‌سازی فایل قرار گیرد.

ارتباط میان این داده‌ها از طریق شناسه دارایی و ارجاع‌های مشخص برقرار شود.

این تفکیک به معنای حذف ارتباط میان داده‌ها نیست؛ بلکه به معنای انتخاب محل ذخیره‌سازی متناسب با ماهیت هر داده است.

۳.۳. NFT و استاندارد ERC-721

توکن غیرقابل‌تعویض (Non-Fungible Token) یک توکن دارای هویت متمایز است که می‌تواند برای نمایش یک دارایی منحصربه‌فرد به کار رود.

استاندارد ERC-721 در شبکه‌های سازگار با ماشین مجازی اتریوم، قواعد مشترکی برای ایجاد و مدیریت این توکن‌ها تعریف می‌کند.

در مدل مفهومی املاک دیجیتال، هر قطعه زمین می‌تواند با یک توکن منحصربه‌فرد نمایش داده شود.

در این حالت، Token ID امکان شناسایی توکن را فراهم می‌کند و قرارداد هوشمند می‌تواند عملیات مرتبط با مالکیت و انتقال را مدیریت کند.

استاندارد ERC-1155 نیز برای مدیریت مجموعه‌ای از توکن‌های قابل‌تعویض و غیرقابل‌تعویض در یک قرارداد طراحی شده است و می‌تواند در سناریوهای مدیریت تجهیزات، اقلام یا دارایی‌های چندنوعی کاربرد داشته باشد.

اما انتخاب استاندارد باید بر اساس مدل دارایی و نیازهای سامانه انجام شود. وجود نام یک استاندارد در معماری پیشنهادی، به معنای فعال‌بودن قطعی آن در پیاده‌سازی یک پروژه نیست.

۳.۴. قرارداد هوشمند و انتقال مالکیت

قرارداد هوشمند (Smart Contract) مجموعه‌ای از قواعد اجرایی است که در محیط بلاکچین پیاده‌سازی می‌شود.

برای نمونه، یک قرارداد مرتبط با NFT می‌تواند عملیات انتقال توکن را طبق قواعد استاندارد مدیریت کند.

بااین‌حال، انتقال توکن و انتقال تمام حقوق مرتبط با یک ملک دیجیتال الزاماً مفاهیم یکسانی نیستند.

برای تعریف یک نظام مالکیت قابل‌اتکا، باید مشخص شود:

کدام عملیات انتقال مجاز هستند؟

آیا محدودیت یا شرطی برای انتقال وجود دارد؟

ارتباط شناسه توکن با شناسه ملک چگونه حفظ می‌شود؟

در صورت تغییر اطلاعات خارج از زنجیره، سازگاری داده‌ها چگونه کنترل می‌شود؟

چه سازوکاری برای رسیدگی به خطا یا تعارض اطلاعات وجود دارد؟

این پرسش‌ها نشان می‌دهند که طراحی مالکیت دیجیتال صرفاً انتخاب یک استاندارد NFT نیست؛ بلکه به طراحی قواعد داده‌ای و اجرایی نیز نیاز دارد.

۴. استانداردهای دارایی‌های سه‌بعدی

پس از تعریف زمین و مشخص‌شدن ساختار مالکیت، باید امکان ایجاد و واردکردن ساختمان‌ها و سایر اجزای سه‌بعدی فراهم شود.

در این مرحله، استانداردهای تبادل داده سه‌بعدی اهمیت پیدا می‌کنند.

یک مدل سه‌بعدی ممکن است در نرم‌افزارهای مختلف طراحی شود، اما برای استفاده در محیط اجرا باید بتوان هندسه، متریال‌ها، بافت‌ها و سایر اطلاعات لازم را به شکلی سازگار منتقل کرد.

۴.۱. فرمت OBJ

فرمت OBJ یکی از قالب‌های شناخته‌شده برای ذخیره‌سازی هندسه سه‌بعدی است.

این قالب می‌تواند اطلاعاتی مانند موارد زیر را نگهداری کند:

مختصات رأس‌ها (Vertices).

اطلاعات سطوح و وجوه (Faces).

مختصات UV.

نرمال‌ها (Normals).

اطلاعات متریال معمولاً از طریق فایل جانبی MTL ارجاع داده می‌شوند.

مزیت OBJ سادگی و پشتیبانی گسترده در ابزارهای مدل‌سازی است؛ اما این قالب برای مدیریت کامل صحنه‌های پیچیده تعاملی، انیمیشن و ساختارهای پیشرفته دارایی طراحی نشده است.

۴.۲. فرمت glTF و GLB

glTF که مخفف GL Transmission Format است، با هدف انتقال کارآمد دارایی‌های سه‌بعدی طراحی شده است.

این استاندارد می‌تواند اطلاعات هندسه، متریال، بافت، سلسله‌مراتب اشیا و در سناریوهای پشتیبانی‌شده، انیمیشن را در ساختاری قابل‌استفاده برای موتورهای گرافیکی ارائه کند.

دو شکل متداول آن عبارت‌اند از:

glTF: قالبی که معمولاً از فایل JSON و منابع جانبی مانند فایل‌های باینری و تصاویر تشکیل می‌شود.

GLB: نسخه باینری glTF که امکان بسته‌بندی بخش‌های مختلف دارایی در یک فایل واحد را فراهم می‌کند.

برای مثال، ساختمانی که در یک نرم‌افزار سه‌بعدی طراحی شده است، می‌تواند پس از خروجی‌گرفتن به GLB وارد محیط اجرا شود. موتور گرافیکی سپس اطلاعات هندسی و متریال آن را پردازش می‌کند.

از این منظر، glTF/GLB برای انتقال دارایی‌های سه‌بعدی در محیط‌های بلادرنگ کاربرد مهمی دارند.

۴.۳. استاندارد 3D Tiles

در محیط‌های وسیع، مدیریت تعداد زیادی مدل سه‌بعدی و داده‌های مکانی می‌تواند به مسئله‌ای پیچیده تبدیل شود.

استاندارد 3D Tiles برای مدیریت و انتقال داده‌های سه‌بعدی حجیم و مکانی توسعه یافته است.

این استاندارد امکان سازمان‌دهی داده‌ها در ساختار سلسله‌مراتبی و بارگذاری تدریجی آن‌ها را فراهم می‌کند.

برای نمونه، در نمایش یک محیط شهری گسترده، لازم نیست تمام جزئیات همه ساختمان‌ها در هر لحظه بارگذاری شوند. سیستم می‌تواند بر اساس موقعیت دوربین و سطح جزئیات موردنیاز، داده‌های مناسب را دریافت کند.

این روش با مفهوم LOD یا Level of Detail ارتباط دارد.

LOD به سیستم اجازه می‌دهد برای فاصله‌های مختلف دوربین، نسخه‌هایی با پیچیدگی هندسی متفاوت نمایش دهد.

در نتیجه، بار پردازشی کاهش پیدا می‌کند و تجربه بصری پایدارتری به دست می‌آید.

البته 3D Tiles جایگزین فرمت‌هایی مانند GLB نیست؛ بلکه در لایه سازمان‌دهی، توزیع و بارگذاری داده‌های سه‌بعدی حجیم نقش متفاوتی دارد.

۵. موتورهای گرافیکی و مدیریت منابع

داده‌های هندسی و مدل‌های سه‌بعدی زمانی برای کاربر قابل مشاهده می‌شوند که در یک محیط اجرا پردازش شوند.

موتورهای گرافیکی (Game Engines) این وظیفه را بر عهده دارند.

موتورهایی مانند Unity ابزارهایی برای مدیریت صحنه، پردازش هندسه، متریال‌ها، نورپردازی، دوربین و تعاملات فراهم می‌کنند.

در معماری املاک دیجیتال، موتور گرافیکی باید بتواند اطلاعات مربوط به زمین و ساختمان را دریافت کند، آن‌ها را در موقعیت صحیح قرار دهد و در هر فریم تصویر مناسب را تولید کند.

اما این فرآیند تنها به نمایش مدل محدود نیست.

۵.۱. مدیریت Scene و Transform

هر شیء در یک صحنه سه‌بعدی دارای اطلاعات موقعیت، چرخش و مقیاس است.

این اطلاعات معمولاً در قالب Transform مدیریت می‌شوند:

Position: موقعیت شیء.

Rotation: جهت‌گیری شیء.

Scale: مقیاس شیء.

در یک محیط املاک دیجیتال، تبدیل مختصات ملک به مختصات صحنه اهمیت زیادی دارد.

برای مثال، اگر موقعیت یک ساختمان در پایگاه داده بر اساس دستگاه مختصات جهانی ذخیره شده باشد، موتور گرافیکی باید آن را به مختصات محلی صحنه تبدیل کند.

عدم هماهنگی میان این دو دستگاه مختصات می‌تواند باعث جابه‌جایی، چرخش یا مقیاس نامناسب مدل شود.

به همین دلیل، تعریف یک لایه تبدیل مختصات (Coordinate Transformation Layer) اهمیت دارد.

۵.۲. مدیریت حافظه و منابع

مدل‌های سه‌بعدی از منابع پردازشی و حافظه استفاده می‌کنند.

تعداد زیاد Polygonها، بافت‌های حجیم، متریال‌های پیچیده و اشیای تعاملی می‌توانند فشار زیادی بر GPU و CPU وارد کنند.

برخی از روش‌های متداول مدیریت این منابع عبارت‌اند از:

LOD: کاهش پیچیدگی هندسی مدل بر اساس فاصله دوربین.

Occlusion Culling: حذف پردازش اشیایی که توسط سایر اجزای صحنه پوشیده شده‌اند.

Frustum Culling: پردازش‌نکردن اشیایی که خارج از محدوده دید دوربین قرار دارند.

Texture Compression: کاهش حجم بافت‌ها برای بهینه‌سازی مصرف حافظه.

Batching: گروه‌بندی برخی عملیات ترسیم برای کاهش سربار پردازشی.

Asynchronous Loading: بارگذاری غیرهم‌زمان دارایی‌ها برای جلوگیری از توقف طولانی در جریان اجرای برنامه.

این تکنیک‌ها در محیط‌های گسترده اهمیت بیشتری پیدا می‌کنند؛ زیرا تعداد مدل‌ها و کاربران می‌تواند به‌سرعت افزایش یابد.

۵.۳. بارگذاری تدریجی و مدیریت محیط‌های بزرگ

فرض کنید یک شهر مجازی شامل هزاران ساختمان و قطعه زمین باشد.

بارگذاری تمام مدل‌ها در لحظه ورود کاربر، می‌تواند زمان شروع برنامه و مصرف حافظه را افزایش دهد.

راهکار مناسب، بارگذاری تدریجی (Progressive Loading) است.

در این روش، سیستم ابتدا داده‌های ضروری را بارگذاری می‌کند و سپس بر اساس موقعیت کاربر، محدوده دید و نیازهای تعاملی، منابع بیشتری را دریافت می‌کند.

در چنین معماری‌ای، مدیریت دارایی‌های سه‌بعدی نباید صرفاً در سطح موتور گرافیکی انجام شود. سیستم ذخیره‌سازی، توزیع فایل‌ها، کش‌کردن منابع و مدیریت نسخه‌ها نیز در عملکرد نهایی تأثیر دارند.

بنابراین، کیفیت اجرای یک محیط املاک مجازی به همکاری میان لایه داده، زیرساخت ذخیره‌سازی و موتور گرافیکی وابسته است.

۶. از داده تا بهره‌برداری؛ ارتباط لایه‌های معماری

تا اینجا هر یک از اجزای فنی به‌صورت مستقل بررسی شدند. اما یک سیستم املاک دیجیتال زمانی شکل می‌گیرد که این اجزا در یک چرخه اجرایی به یکدیگر متصل شوند.

برای روشن‌شدن ارتباط میان آن‌ها، می‌توان معماری مفهومی یک ملک دیجیتال را در شش لایه خلاصه کرد:

لایه اول: داده فضایی

شامل مختصات، مرزهای هندسی، مساحت و مشخصات مکانی زمین.

لایه دوم: هویت دارایی

شامل Asset ID، فراداده و ارتباط میان ملک و اطلاعات توصیفی آن.

لایه سوم: مالکیت و تراکنش

شامل VOD، اطلاعات مالکیت، شناسه توکن و سوابق انتقال در صورت استفاده از زیرساخت بلاکچین.

لایه چهارم: دارایی‌های سه‌بعدی

شامل مدل ساختمان، متریال‌ها، بافت‌ها و فایل‌های استاندارد مانند GLB.

لایه پنجم: اجرای گرافیکی

شامل موتور رندرینگ، مدیریت صحنه، تبدیل مختصات، بارگذاری و تعاملات سه‌بعدی.

لایه ششم: بهره‌برداری

شامل تعریف کاربری، ایجاد فضاهای تجاری یا خدماتی و فراهم‌کردن امکان استفاده از محیط توسط کاربران.

ارتباط این لایه‌ها را می‌توان در یک جریان ساده مشاهده کرد:

Spatial Geometry

|

v

Asset ID

|

v

Ownership Layer

(VOD / Blockchain)

|

v

3D Asset Pipeline

(OBJ / glTF / GLB)

|

v

Rendering Engine

(Scene / GPU / LOD)

|

v

Digital Environment

|

v

Commercial Utilization

در این مدل، شناسه دارایی نقش اتصال‌دهنده را دارد. سیستم می‌تواند از طریق این شناسه، هندسه زمین، اطلاعات مالکیت و مدل سه‌بعدی مرتبط را بازیابی کند.

برای مثال، وقتی کاربر یک قطعه تجاری را در نقشه انتخاب می‌کند، رابط کاربری می‌تواند شناسه آن را دریافت کند. سپس سیستم اطلاعات هندسی و مشخصات ملک را از لایه داده بازیابی می‌کند و اطلاعات مالکیت را از زیرساخت مربوطه می‌خواند.

اگر ساختمانی روی آن قطعه تعریف شده باشد، مدل سه‌بعدی مرتبط نیز از مسیر ذخیره‌سازی دریافت و در موتور گرافیکی بارگذاری می‌شود.

در نتیجه، آنچه کاربر به‌عنوان یک ملک واحد مشاهده می‌کند، در پشت صحنه از چندین نوع داده و زیرسیستم مستقل تشکیل شده است.

نمونه عملی: معماری املاک تجاری در متاورس رنگ

در مقاله «راهنمای جامع املاک تجاری در متاورس رنگ»، این مفاهیم در قالب یک ساختار عملیاتی مطرح شده‌اند.

زمین‌های تجاری در محیط متارنگ به‌صورت قطعات هندسی مشخص در نقشه تعریف می‌شوند. موقعیت، محدوده و مشخصات زمین، مبنای شناسایی آن در محیط مجازی هستند.

در لایه مالکیت، مفهوم VOD برای شناسایی و ثبت مالکیت مجازی دارایی در نظر گرفته شده است. همچنین، مقاله به نقش بلاکچین و استانداردهایی مانند ERC-721 برای نمایش دارایی‌های منحصربه‌فرد اشاره می‌کند.

در مرحله توسعه، مالک می‌تواند مدل سه‌بعدی ساختمان موردنظر خود را آماده کند و از قالب‌هایی مانند OBJ یا glTF/GLB برای انتقال دارایی استفاده کند.

در نهایت، مدل وارد محیط سه‌بعدی می‌شود و متناسب با کاربری موردنظر، امکان ایجاد فضای تجاری، اداری یا خدماتی فراهم می‌شود.

این نمونه نشان می‌دهد که معماری املاک دیجیتال تنها به یک فناوری وابسته نیست؛ بلکه از ارتباط میان هندسه، هویت داده‌ای، مالکیت، استانداردهای سه‌بعدی و زیرساخت گرافیکی شکل می‌گیرد.

البته باید توجه داشت که معرفی یک فناوری یا استاندارد در معماری مفهومی، به معنای تأیید استفاده عملی از تمام اجزای آن در پیاده‌سازی فعلی سامانه نیست. برای ارزیابی فنی یک محصول، باید مستندات اجرایی و جزئیات پیاده‌سازی هر لایه نیز بررسی شوند.

جمع‌بندی: ملک دیجیتال یک مدل سه‌بعدی ساده نیست

معماری فنی املاک دیجیتال را نمی‌توان به طراحی یک زمین یا ایجاد یک ساختمان سه‌بعدی محدود کرد.

یک ملک مجازی برای تبدیل‌شدن به دارایی قابل‌مدیریت، به تعریف هندسی دقیق، دستگاه مختصات سازگار، شناسه یکتا، ساختار ثبت مالکیت، استانداردهای تبادل مدل سه‌بعدی و زیرساخت اجرای گرافیکی نیاز دارد.

هر یک از این لایه‌ها مسئله متفاوتی را حل می‌کنند:

هندسه، محدوده و موقعیت دارایی را مشخص می‌کند.

شناسه، امکان ارجاع مستقل به ملک را فراهم می‌سازد.

VOD و زیرساخت مالکیت، اطلاعات مربوط به مالک را سازمان‌دهی می‌کنند.

بلاکچین و NFT می‌توانند سازوکار ثبت و انتقال دارایی را پشتیبانی کنند.

استانداردهای سه‌بعدی، انتقال مدل‌ها میان ابزارهای مختلف را تسهیل می‌کنند.

موتور گرافیکی، داده‌ها را به محیطی قابل مشاهده و تعامل تبدیل می‌کند.

در نهایت، ارزش مهندسی چنین معماری‌ای در جداسازی مسئولیت‌ها و ایجاد ارتباط استاندارد میان آن‌هاست.

وقتی داده‌های هندسی، اطلاعات مالکیت و مدل‌های سه‌بعدی به‌صورت مستقل اما هماهنگ مدیریت شوند، امکان توسعه یک محیط دیجیتال ساختاریافته فراهم می‌شود؛ محیطی که در آن زمین فقط یک عنصر گرافیکی نیست، بلکه دارایی‌ای با هویت، محدوده، اطلاعات مالکیت و قابلیت توسعه فضایی است.

پرسش فنی مهم این است: در طراحی یک سیستم املاک متاورسی، کدام لایه باید مرجع نهایی اطلاعات دارایی باشد؛ پایگاه داده مکانی، سند مالکیت دیجیتال یا قرارداد هوشمند؟ پاسخ به این پرسش، یکی از تصمیم‌های بنیادین در طراحی معماری چنین سامانه‌هایی است.

https://metarang.com/fa/articles/categories/algorithms/BL_10043

Suppose a digital ecosystem has numerous documents regarding software architecture, blockchain infrastructure, 3D design, economic models, security, and organizational processes. Each of these documents holds valuable information; but can we directly use all of this information to create questions?

The answer is no. A technical document does not necessarily have the proper structure for generating questions. Its information might be scattered across several sections, some concepts may depend on a specific version of the software, or proving a correct answer might require a more precise reference.

The main issue is not just gathering information; rather, it is converting information into structured, evaluable, and traceable data.

In Metarang, this issue forms the basis for designing the knowledge base and the technical pipeline for extracting Q&A challenge questions. This structure is developed within the Index Civilization Digital Metarang notebook, aiming to organize 369 existing questions and provide a standard platform for generating new ones.

In this article, we examine where this process begins, how data is categorized, what characteristics a standard question possesses, and how the correct answer is validated.

Section 1: Why Do We Need a Knowledge Base Before Generating Questions?

Imagine Metarang’s technical team has documentation on backend architecture, WebSocket communications, smart contract structures, and executing 3D projects in Unity.

If questions are to be generated from each, the first challenge is finding reliable information.

For example, a question might be raised about how services communicate. Its answer must match the actual architecture of the system, not a general perception of the technology used.

The same issue exists for economic questions. If a question is designed regarding the PSC and PSD tokens, the answer must align with Metarang’s documented economic model.

Therefore, before generating questions, three issues must be resolved:

• Extract information from reliable sources.
• Place each piece of data in the appropriate specialized domain.
• Maintain the link between the data and the original document.

This is where the concept of a Knowledge Base becomes important.

A knowledge base is an organized collection of information that enables the storage, categorization, search, and reuse of data.

In Metarang’s architecture, the Index Civilization Digital Metarang notebook acts as the organizing center for this information.

The key point is that the purpose of this knowledge base is not merely to store document text; rather, it must be possible to build questions from the extracted information, review their answers, and ultimately produce standard data to be used in the challenge management system.

Section 2: Where Do Knowledge Sources Come From and How Are They Categorized?

The first stage in question generation is identifying the information source.

In Metarang, data is extracted based on official documents and technical, economic, security, and ecosystem design information.

To prevent the irregular mixing of topics, knowledge sources are organized into several main domains:

1. Software Infrastructure and System Architecture

This group includes documentation related to the backend, web, and inter-service communication. For example:

• Clean Architecture
• gRPC-Web (RPC-based web communication technology)
• Envoy (Proxy and network communication management layer)
• WebSocket (Bidirectional real-time communication)
• Revalidation-Based Tag
• Prisma and PostgreSQL

This information can serve as the basis for designing questions about service structures, communication methods, and data management.

2. Rendering and Cross-Platform Infrastructure

This category includes documents related to Metarang-Unity, scene architecture, reference prefabs, the Addressables system, and running projects on WebGL, Quest, and Windows. For instance, if there is documentation about Addressables, a question can be designed regarding resource management and loading in the Unity project.

3. Economy and Decentralized Technologies

This category includes information regarding:

• PSC and PSD tokens
• Disinflationary issuance model
• Liquidity pools
• Smart contracts
• Arbitrum L2 infrastructure

In this section, the key point is maintaining the connection between the question and the economic model and approved documentation, because a change in an economic parameter can alter a question’s answer.

4. Metarang Algorithms and Internal Logic

This domain includes information regarding citizenship level score calculations, impact thresholds, ZKP-based anti-collusion mechanisms, hourly profits, and level-step mechanics. These sources are suitable for generating questions that require an understanding of the system’s operational logic.

5. Security and Organizational Processes

STRIDE, OWASP, AFTA requirements, contractor agreements, source code delivery, and workflow automation with AI Agents and n8n fall into this group.

Knowledge Source Categorization Table

DomainSample SourcesPotential Question TopicSoftwareGo, Node.js, PostgreSQLArchitecture and service communication3DUnity, WebGL, AddressablesResource management and renderingEconomyPSC, PSD, Smart ContractEconomic model and tokensAlgorithmZKP, Scoring, Impact ThresholdCalculation logicSecuritySTRIDE, OWASP, AFTARisk control and security

This categorization helps ensure that each question belongs to a specific domain, allowing its subject origin to be identified during searching, evaluation, or question bank development.

Of course, categorization alone is not enough. Each source must be converted into information that can be processed in subsequent stages.

Section 3: How is a Standard Question Formed?

After identifying and categorizing sources, the question generation phase begins. At this stage, the goal is to convert a specific piece of knowledge into an evaluable query.

For example, suppose Metarang’s documentation mentions WebSocket technology. Simply asking “What is WebSocket?” is not necessarily a suitable question to assess specialized ecosystem knowledge. The question must be connected to documented information and its specific application within the reviewed structure.

The question generation process can be explained in four steps:

• Step 1: Topic Selection — First, a specific topic is selected from the knowledge base; for example, real-time communications in Metarang’s software infrastructure.
• Step 2: Extracting a Valid Proposition — A specific proposition is extracted from the documentation related to that topic. This proposition must contain information whose correctness can be verified through the primary source.
• Step 3: Converting the Proposition into a Query — The extracted proposition is rewritten in a way that assesses the user’s knowledge regarding that exact topic.
• Step 4: Designing Options — Four distinct options are considered for the question, with only one of them being the correct answer.

An Example of Data-to-Question Conversion Logic

Suppose an official software architecture document specifies the use of PostgreSQL in the data structure. The process of converting information into a question will look like this:

• Stage: Software Architecture Document
• Domain: Software Infrastructure
• Proposition: PostgreSQL is used in the documented architecture
• Question: Which database is introduced in the architecture document?
• Correct Option: PostgreSQL
• Reference: Corresponding architecture document

This example illustrates the method of constructing a question and does not represent a registered question in the current bank.

What Are the Characteristics of a Standard Question?

For a question to be eligible to enter the challenge bank, it must pass several criteria:

• Have a specific topic and a discernible scope.
• Have a provable correct answer.
• Have four distinct options.
• Avoid ambiguity and multi-answer scenarios.
• Comply with Metarang’s official documentation.
• Have a defined difficulty level.
• Provide an exact reference to verify the correct answer.

The concept of a Distractor is also important here. A distractor is an incorrect answer included as one of the selectable choices in question design. These options should not be designed in a way that multiple answers are logically acceptable. The goal is to build a question that evaluates real knowledge, rather than one answerable simply by guessing or eliminating unrelated options.

Section 4: How is the Correct Answer Validated?

One of the most critical stages of the pipeline is validating the correct answer. In a specialized question bank, registering an answer as correct is not enough; it must be clear on what basis this answer was chosen and which document confirms it.

In Metarang’s architecture, the correct answer must be directly extractable from reliable ecosystem sources, including:

• Project source code
• Official documentation
• Approved architecture
• Whitepaper
• Related technical and economic documents

For example, if a question is designed regarding the score calculation logic for citizenship levels, the answer must match the documented algorithm. If the answer is extracted from an architecture document, the reference must remain tied to that same document. If the topic relates to the actual behavior of a software module, examining the code or related technical documentation becomes important.

What Role Does Source Reference Play?

Source Reference is the information that specifies the origin of a question and its answer. In Metarang’s data structure, the source_reference field is intended to maintain this connection.

The presence of this field ensures that the correct answer is not just a stored value in the question bank, but can be traced back to the original document or reference. For example, when reviewing a question, the following can be determined:

• From which knowledge domain was the question extracted?
• Which document served as the basis for its design?
• Which part of the document does the correct answer match?
• Is the used information dependent on a specific version of the system?

Why Does Version Scope Matter?

In software projects, information may change with the release of new versions. For instance, Metarang has had various versions ranging from V1.1.21 to V1.1.35. If a question is designed regarding user interface changes or responsive behavior, it must be clear which version the information belongs to. Otherwise, an answer that was correct in one version might no longer be valid in another.

Therefore, connecting the question to the version scope is an important part of technical knowledge management. This approach also allows questions to be re-evaluated when documents or architectures change.

Section 5: How is the Challenge Lifecycle Managed?

After generating and validating a question, the data enters the challenge management structure. At this stage, the system must manage financial capacity, creator access levels, challenge prioritization, response status, and information archiving, in addition to storing the question.

Who Can Create Challenges?

In Metarang’s defined structure, the ability to create and configure challenges is considered for the Journalist level (equivalent to the second level with 1000 points) and higher levels. Therefore, ordinary citizen-level users do not have the ability to create challenges or design questions within this structure.

How is Each Challenge’s Capacity Calculated?

The number of registerable questions in each challenge must align with the allocated budget. The capacity calculation relationship is defined as follows:

$$\text{Capacity} = \left\lfloor \frac{\text{Budget}}{\text{Reward}} \right\rfloor$$

In this relation:

• Budget: Total budget allocated to the challenge
• Reward: The reward for each question
• Capacity: Maximum number of registerable questions

The floor sign means that the division result is rounded down to the lower integer. For example, if a challenge’s budget is 1000 units and the reward for each question is 100 units, the challenge capacity will be 10 questions. This mechanism prevents registering questions beyond the financial capacity of the challenge. Assets such as red, blue, and yellow colors, PSC, and other defined assets can also be used to fund the challenge budget.

How Are Challenges Prioritized?

To manage the list of challenges, the Engine Discovery Priority is considered. One of the main criteria of this engine is the reward value allocated to each question. Consequently, challenges with higher reward values will be easier to identify and prioritize in the suggested list.

How Is Re-answering Prevented?

One of the issues in Q&A systems is the infinite repetition of a question by a user. In Metarang’s structure, to prevent re-answering a question after an incorrect response, the question ID is locked for that specific user within the participant structure. Thus, the ID-locking mechanism alongside point rules helps reduce the possibility of infinite question repetition.

How Does a Challenge Lifecycle End?

Each challenge enters the Archived status upon reaching one of the following conditions:

• Budget exhaustion
• Completion of response capacity
• Reaching the expiration time

The important point is that archiving does not mean deleting information. Information such as the number of participants, the ratio of correct to wrong answers, and the amount of distributed assets are preserved so they can be used in future analyses and reviewing system history.

Section 6: How is Final Output Generated and Quality Controlled?

After knowledge extraction, question generation, answer validation, and information registration, it is time to standardize the output. At this stage, data must be placed in a format that can be utilized in the notebook, management panel, and future processes.

What Is the Structure of Each Question?

For each question, a set of specific fields is considered:

FieldApplicationUnique IDIndependent identification of the questionSpecialized CategoryDetermining the knowledge domainSourceSpecifying information originVersion ScopeDetermining the related versionQuestion TextContent of the queryFour OptionsSelectable choicesCorrect AnswerDetermining the valid optionDifficulty LevelClassifying difficulty degreeAuthor IDIdentifying the question creatorReward TypeSpecifying the prize structureAd InformationAd title and link

To identify questions, an ID structure similar to the following sample is considered:Q-V1135-NET-001 This ID allows the identification of the version, specialized domain, and question number.

How Is Data Standardized for Use in the System?

Data Standardization means converting information into a uniform format usable across different parts of the system. For example, if questions are stored in different formats, transferring them to the management panel or automated processing will be harder. Therefore, the pipeline must produce a clear, integrated output. Two main formats are considered for this purpose:

1. Excel

This output is used to transfer questions to the challenge management system. The main columns of the file include:

• Question: Question text
• Opt1: First option
• Opt2: Second option
• Opt3: Third option
• Opt4: Fourth option
• Answer: Correct answer
• Author: Author
• Title_Ad: Ad title
• Link_Ad: Ad link

2. JSON

The JSON (JavaScript Object Notation) format is a standard text structure for exchanging data between software. This format enables transferring question information to software services and tools.

How Is Question Quality Controlled?

Generating an Excel or JSON file is not the end of the process. To ensure the quality of the question bank, a separate document is prepared for judges and the scientific assembly. In this document, the source of each question, the reason for the correctness of the right option, and the exact reference to the related document, commit, task, or architecture will be recorded. This allows independent review of the questions.

How Is the Pipeline’s Technical Quality Controlled?

The question generation infrastructure, like other software services, must go through development and quality control cycles. The main stages of this process include:

• Development in the project’s dedicated repository and designated branch, complying with GitFlow or Feature Branch
• Deployment of the candidate version in the Staging or Development Server environment
• Executing acceptance tests and Smoke Tests
• Updating README and execution, testing, and environment variable documentation
• Passing the Quality Gate, including Linting and static analysis
• Checking source code vulnerabilities and dependencies
• Establishing proper connection to Sentry for recording and tracking critical errors
• Executing automated tests for critical system logic
• Using the TDD approach in developing core logic
• Code merging after technical team or supervisor approval and successful CI/CD pipelines
• Reviewing logs, errors, and monitoring metrics post-merge

Quality Gate is a set of technical criteria that code must meet before moving to the next development stage. Also, CI/CD (Continuous Integration and Continuous Delivery/Deployment) refers to the set of automated processes for checking, building, testing, and releasing software. These controls help identify logical, data, and security errors before widespread system use.

Knowledge-to-Question Conversion Cycle Diagram

The overall pipeline process can be summarized as follows:

• Official Metarang documents
• $\downarrow$
• Extracting information and valid propositions
• $\downarrow$
• Categorizing knowledge into specialized domains
• $\downarrow$
• Generating questions and designing four options
• $\downarrow$
• Validating the correct answer and registering the source
• $\downarrow$
• Standardizing data structure
• $\downarrow$
• Generating Excel and JSON outputs
• $\downarrow$
• Judge review and technical quality control
• $\downarrow$
• Entering the challenge management cycle and information archiving

Conclusion: Why Does This Architecture Matter?

Transforming scattered documents into a usable question bank is not limited to merely producing a few Q&As. This process requires an infrastructure capable of preserving data origins, organizing information into clear categories, generating evaluable questions, and keeping the accuracy of answers connected to reliable sources.

In Metarang’s architecture, the Index Civilization Digital Metarang notebook plays the organizing center role for this knowledge. The goal is to cover and organize the 369 existing questions and create a platform for the continuous generation of new questions.

Combining resource categorization, data standardization, answer referencability, financial capacity management, anti-repetition mechanisms, information archiving, and technical quality control creates a traceable cycle for challenge management. In such a structure, each question is not just a competitive query; rather, it is a structured unit of Metarang’s documented knowledge whose origin can be checked, accuracy measured, and reused in subsequent processes.

The more important question is: When an ecosystem’s knowledge is converted into standard and evaluable data, what capacities will be created for developing education, expertise assessment, and knowledge management within it?

https://metarang.com/fa/articles/categories/algorithms/BL_10042

فرض کنیم یک اکوسیستم دیجیتال، مستندات متعددی درباره معماری نرم‌افزار، زیرساخت بلاکچین، طراحی سه‌بعدی، مدل اقتصادی، امنیت و فرآیندهای سازمانی در اختیار دارد. هرکدام از این مستندات اطلاعات ارزشمندی را نگهداری می‌کنند؛ اما آیا می‌توان مستقیماً از تمام این اطلاعات برای ساخت سؤال استفاده کرد؟

پاسخ منفی است. یک سند فنی لزوماً ساختار مناسبی برای تولید سؤال ندارد. ممکن است اطلاعات آن در چند بخش پراکنده شده باشد، بعضی مفاهیم به نسخه مشخصی از نرم‌افزار وابسته باشند یا برای اثبات یک پاسخ صحیح، به ارجاع دقیق‌تری نیاز باشد.

مسئله اصلی فقط جمع‌آوری اطلاعات نیست؛ بلکه تبدیل اطلاعات به داده‌ای ساختاریافته، قابل ارزیابی و قابل ردیابی است.

در متارنگ، این مسئله مبنای طراحی پایگاه دانش و پایپ‌لاین فنی استخراج سؤالات چالش پرسش و پاسخ قرار گرفته است. این ساختار در نوت‌بوک Index Civilization Digital Metarang توسعه پیدا می‌کند و هدف آن سازماندهی ۳۶۹ سؤال موجود و فراهم کردن بستری استاندارد برای تولید سؤالات جدید است.

در این مقاله بررسی می‌کنیم که این فرآیند از کجا آغاز می‌شود، داده‌ها چگونه دسته‌بندی می‌شوند، سؤال استاندارد چه ویژگی‌هایی دارد و پاسخ صحیح چگونه اعتبارسنجی می‌شود.

بخش اول: چرا پیش از تولید سؤال به پایگاه دانش نیاز داریم؟

تصور کنید تیم فنی متارنگ مستنداتی درباره معماری بک‌اند، ارتباطات WebSocket، ساختار قراردادهای هوشمند و اجرای پروژه سه‌بعدی در Unity در اختیار دارد.

اگر قرار باشد از هرکدام سؤال تولید شود، نخستین چالش پیدا کردن اطلاعات معتبر است.

برای مثال، ممکن است یک سؤال درباره نحوه ارتباط سرویس‌ها مطرح شود. پاسخ آن باید با معماری واقعی سیستم مطابقت داشته باشد، نه با برداشت عمومی از فناوری مورد استفاده.

همین مسئله درباره سؤالات اقتصادی نیز وجود دارد. اگر سؤالی درباره توکن‌های PSC و PSD طراحی شود، پاسخ باید با مدل اقتصادی مستندشده متارنگ هماهنگ باشد.

بنابراین، پیش از تولید سؤال باید سه مسئله حل شود:

اطلاعات از منابع معتبر استخراج شوند.

هر داده در حوزه تخصصی مناسب قرار بگیرد.

ارتباط میان داده و سند اصلی حفظ شود.

اینجاست که مفهوم Knowledge Base (پایگاه دانش) اهمیت پیدا می‌کند.

پایگاه دانش مجموعه‌ای سازمان‌یافته از اطلاعات است که امکان ذخیره‌سازی، دسته‌بندی، جست‌وجو و استفاده مجدد از داده‌ها را فراهم می‌کند.

در معماری متارنگ، نوت‌بوک Index Civilization Digital Metarang نقش مرکز سازماندهی این اطلاعات را بر عهده دارد.

نکته مهم این است که هدف این پایگاه صرفاً نگهداری متن مستندات نیست؛ بلکه باید بتوان از اطلاعات استخراج‌شده، سؤال ساخت، پاسخ آن را بررسی کرد و در نهایت داده‌ای استاندارد برای استفاده در سیستم مدیریت چالش تولید کرد.

بخش دوم: منابع دانش از کجا می‌آیند و چگونه دسته‌بندی می‌شوند؟

اولین مرحله در تولید سؤال، شناسایی منبع اطلاعات است.

در متارنگ، داده‌ها بر اساس مستندات رسمی و اطلاعات فنی، اقتصادی، امنیتی و طراحی اکوسیستم استخراج می‌شوند.

برای جلوگیری از ترکیب نامنظم موضوعات، منابع دانش در چند حوزه اصلی سازماندهی شده‌اند.

۱. زیرساخت نرم‌افزاری و معماری سیستم

این گروه شامل مستندات مربوط به بک‌اند، وب و ارتباط میان سرویس‌هاست.

برای مثال:

Clean Architecture (معماری پاک)

gRPC-Web (فناوری ارتباطی مبتنی بر RPC برای وب)

Envoy (پراکسی و لایه مدیریت ارتباطات شبکه)

WebSocket (ارتباط دوطرفه و بلادرنگ)

Revalidation Based-Tag (سازوکار بازاعتبارسنجی مبتنی بر برچسب)

Prisma و PostgreSQL

این اطلاعات می‌توانند مبنای طراحی سؤال درباره ساختار سرویس‌ها، شیوه ارتباطات و مدیریت داده باشند.

۲. رندرینگ و زیرساخت چندسکویی

در این دسته، مستندات مرتبط با Metarang-Unity، معماری صحنه‌ها، Prefabهای مرجع، سیستم Addressables و اجرای پروژه روی WebGL، Quest و Windows قرار می‌گیرند.

برای مثال، اگر مستندی درباره Addressables وجود داشته باشد، می‌توان از آن سؤالی درباره نحوه مدیریت و بارگذاری منابع در پروژه Unity طراحی کرد.

۳. اقتصاد و فناوری‌های غیرمتمرکز

این دسته شامل اطلاعات مربوط به:

توکن‌های PSC و PSD

مدل انتشار پادکاهشی

استخرهای نقدینگی

قراردادهای هوشمند

زیرساخت Arbitrum L2

است.

در این بخش، نکته مهم حفظ ارتباط سؤال با مدل اقتصادی و مستندات مصوب است؛ زیرا تغییر در یک پارامتر اقتصادی می‌تواند پاسخ یک سؤال را تغییر دهد.

۴. الگوریتم‌ها و منطق داخلی متارنگ

در این حوزه، اطلاعات مربوط به محاسبه امتیاز سطوح شهروندی، حد تأثیر، مکانیزم‌های ضدتبانی مبتنی بر ZKP، سود ساعت‌شمار و مکانیک پله‌های سطوح قرار می‌گیرند.

این منابع برای تولید سؤالاتی مناسب هستند که به درک منطق عملکرد سیستم نیاز دارند.

۵. امنیت و فرآیندهای سازمانی

مستندات STRIDE، OWASP، الزامات افتا، قراردادهای پیمانکاران، تحویل کدهای منبع و اتوماسیون گردش کار با AI Agent و n8n در این گروه قرار می‌گیرند.

جدول دسته‌بندی منابع دانش

حوزه

نمونه منابع

موضوع احتمالی سؤال

نرم‌افزار

Go، Node.js، PostgreSQL

معماری و ارتباط سرویس‌ها

سه‌بعدی

Unity، WebGL، Addressables

مدیریت منابع و رندرینگ

اقتصاد

PSC، PSD، قرارداد هوشمند

مدل اقتصادی و توکن

الگوریتم

ZKP، امتیازدهی، حد تأثیر

منطق محاسبات

امنیت

STRIDE، OWASP، افتا

کنترل ریسک و امنیت

این دسته‌بندی کمک می‌کند هر سؤال به یک حوزه مشخص تعلق داشته باشد و هنگام جست‌وجو، ارزیابی یا توسعه بانک سؤال، منشأ موضوع آن قابل شناسایی باشد.

البته دسته‌بندی به‌تنهایی کافی نیست. هر منبع باید به اطلاعاتی تبدیل شود که بتوان آن را در مراحل بعدی پردازش کرد.

بخش سوم: سؤال استاندارد چگونه شکل می‌گیرد؟

پس از شناسایی و دسته‌بندی منابع، مرحله تولید سؤال آغاز می‌شود.

در این مرحله، هدف تبدیل یک بخش مشخص از دانش به یک پرسش قابل ارزیابی است.

برای مثال، فرض کنیم در مستندات متارنگ به فناوری WebSocket اشاره شده است.

صرفاً پرسیدن اینکه «WebSocket چیست؟» لزوماً سؤال مناسبی برای سنجش دانش تخصصی اکوسیستم نیست.

سؤال باید به اطلاعات مستند و کاربرد مشخص آن در ساختار مورد بررسی متصل باشد.

فرآیند تولید سؤال را می‌توان در چهار گام توضیح داد:

گام اول: انتخاب موضوع

ابتدا یک موضوع مشخص از پایگاه دانش انتخاب می‌شود؛ برای مثال ارتباطات بلادرنگ در زیرساخت نرم‌افزاری متارنگ.

گام دوم: استخراج گزاره معتبر

از مستندات مربوط به آن موضوع، یک گزاره مشخص استخراج می‌شود.

این گزاره باید اطلاعاتی داشته باشد که بتوان صحت آن را از طریق منبع اصلی بررسی کرد.

گام سوم: تبدیل گزاره به پرسش

گزاره استخراج‌شده به شکلی بازنویسی می‌شود که دانش کاربر را درباره همان موضوع ارزیابی کند.

گام چهارم: طراحی گزینه‌ها

برای سؤال چهار گزینه متمایز در نظر گرفته می‌شود که تنها یکی از آن‌ها پاسخ صحیح باشد.

یک نمونه از منطق تبدیل داده به سؤال

فرض کنیم یک سند رسمی درباره معماری نرم‌افزاری، استفاده از PostgreSQL را در ساختار داده مشخص کرده است.

فرآیند تبدیل اطلاعات به سؤال به این شکل خواهد بود:

مرحله

داده یا عملیات

منبع

مستند معماری نرم‌افزار

حوزه

زیرساخت نرم‌افزاری

گزاره

PostgreSQL در معماری مستندشده استفاده شده است

سؤال

کدام پایگاه داده در مستند معماری معرفی شده است؟

گزینه صحیح

PostgreSQL

ارجاع

سند معماری مربوطه

این مثال، شیوه ساخت سؤال را نشان می‌دهد و به‌منزله معرفی یک سؤال ثبت‌شده در بانک فعلی نیست.

سؤال استاندارد چه ویژگی‌هایی دارد؟

برای اینکه سؤال قابلیت ورود به بانک چالش را داشته باشد، باید از چند معیار عبور کند:

موضوع مشخص و محدوده قابل تشخیص داشته باشد.

پاسخ صحیح آن قابل اثبات باشد.

چهار گزینه متمایز داشته باشد.

از ابهام و چندپاسخی بودن جلوگیری کند.

با مستندات رسمی متارنگ مطابقت داشته باشد.

سطح دشواری مشخصی داشته باشد.

منبع دقیق برای بررسی پاسخ صحیح ارائه کند.

در اینجا مفهوم Distractor (گزینه انحرافی) نیز اهمیت دارد. گزینه انحرافی پاسخی است که صحیح نیست، اما در طراحی سؤال به‌عنوان یکی از گزینه‌های انتخابی قرار می‌گیرد.

این گزینه‌ها نباید به شکلی طراحی شوند که چند پاسخ از نظر منطقی قابل قبول باشند.

هدف، ساخت سؤالی است که دانش واقعی را ارزیابی کند، نه اینکه صرفاً با حدس زدن یا حذف گزینه‌های نامرتبط قابل پاسخ باشد.

بخش چهارم: پاسخ صحیح چگونه اعتبارسنجی می‌شود؟

یکی از مهم‌ترین مراحل پایپ‌لاین، اعتبارسنجی پاسخ صحیح است.

در یک بانک سؤال تخصصی، ثبت یک پاسخ به‌عنوان گزینه صحیح کافی نیست. باید مشخص باشد این پاسخ بر چه اساسی انتخاب شده و کدام سند آن را تأیید می‌کند.

در معماری متارنگ، پاسخ صحیح باید مستقیماً از منابع معتبر اکوسیستم قابل استخراج باشد؛ از جمله:

کد منبع پروژه

مستندات رسمی

معماری مصوب

وایت‌پیپر

مستندات فنی و اقتصادی مرتبط

برای مثال، اگر سؤالی درباره منطق محاسبه امتیاز در سطوح شهروندی طراحی شود، پاسخ باید با الگوریتم مستندشده مطابقت داشته باشد.

اگر پاسخ از یک سند معماری استخراج شده باشد، ارجاع باید به همان سند متصل بماند. اگر موضوع به رفتار واقعی یک ماژول نرم‌افزاری مربوط باشد، بررسی کد یا مستندات فنی مرتبط اهمیت پیدا می‌کند.

Source Reference چه نقشی دارد؟

Source Reference (ارجاع به منبع) اطلاعاتی است که منشأ یک سؤال و پاسخ آن را مشخص می‌کند.

در ساختار داده متارنگ، فیلد source_reference برای حفظ این ارتباط در نظر گرفته شده است.

وجود این فیلد باعث می‌شود پاسخ صحیح فقط یک مقدار ذخیره‌شده در بانک سؤال نباشد؛ بلکه بتوان آن را به سند یا مرجع اصلی بازگرداند.

برای مثال، هنگام بررسی یک سؤال می‌توان این موارد را مشخص کرد:

سؤال از کدام حوزه دانش استخراج شده است؟

کدام سند مبنای طراحی آن بوده است؟

پاسخ صحیح با کدام بخش از سند مطابقت دارد؟

آیا اطلاعات مورد استفاده به نسخه مشخصی از سیستم وابسته است؟

چرا محدوده نسخه اهمیت دارد؟

در پروژه‌های نرم‌افزاری، اطلاعات ممکن است با انتشار نسخه‌های جدید تغییر کنند.

برای نمونه، متارنگ نسخه‌های مختلفی از جمله V1.1.21 تا V1.1.35 داشته است.

اگر سؤالی درباره تغییرات رابط کاربری یا رفتار ریسپانسیو طراحی شود، باید مشخص باشد اطلاعات مربوط به کدام نسخه است.

در غیر این صورت، ممکن است پاسخی که در یک نسخه صحیح بوده، در نسخه دیگری دیگر اعتبار نداشته باشد.

بنابراین، ارتباط سؤال با محدوده نسخه یکی از بخش‌های مهم مدیریت دانش فنی است.

این رویکرد همچنین امکان بررسی مجدد سؤال‌ها را در زمان تغییر مستندات یا معماری فراهم می‌کند.

بخش پنجم: چرخه چالش چگونه مدیریت می‌شود؟

پس از تولید و اعتبارسنجی سؤال، داده وارد ساختار مدیریت چالش می‌شود.

در این مرحله، سیستم باید علاوه بر نگهداری سؤال، ظرفیت مالی، سطح دسترسی ایجادکنندگان، اولویت‌بندی چالش‌ها، وضعیت پاسخ‌دهی و آرشیو اطلاعات را مدیریت کند.

چه کسانی امکان ایجاد چالش دارند؟

در ساختار تعریف‌شده متارنگ، امکان ایجاد و پیکربندی چالش از سطح خبرنگار، معادل سطح دوم با ۱۰۰۰ امتیاز، و سطوح بالاتر در نظر گرفته شده است.

بنابراین، کاربران سطح شهروند عادی امکان ایجاد چالش یا طرح سؤال در این ساختار را ندارند.

ظرفیت هر چالش چگونه محاسبه می‌شود؟

تعداد سؤال‌های قابل ثبت در هر چالش باید با بودجه تخصیص‌یافته هماهنگ باشد.

رابطه محاسبه ظرفیت به شکل زیر تعریف شده است:

[

Capacity = \left\lfloor \frac{Budget}{Reward} \right\rfloor

]

در این رابطه:

Budget: کل بودجه اختصاص‌یافته به چالش

Reward: جایزه هر سؤال

Capacity: حداکثر تعداد سؤال قابل ثبت

علامت کف به این معناست که نتیجه تقسیم به عدد صحیح پایین‌تر گرد می‌شود.

برای مثال، اگر بودجه یک چالش ۱۰۰۰ واحد و جایزه هر سؤال ۱۰۰ واحد باشد، ظرفیت چالش برابر ۱۰ سؤال خواهد بود.

این سازوکار مانع از ثبت سؤال بیشتر از ظرفیت مالی چالش می‌شود.

دارایی‌هایی مانند رنگ قرمز، آبی و زرد، PSC و سایر دارایی‌های تعریف‌شده نیز می‌توانند در تأمین بودجه چالش مورد استفاده قرار گیرند.

چالش‌ها چگونه اولویت‌بندی می‌شوند؟

برای مدیریت فهرست چالش‌ها، موتور Engine Discovery Priority در نظر گرفته شده است.

یکی از معیارهای اصلی این موتور، ارزش جایزه اختصاص‌یافته به هر سؤال است.

در نتیجه، چالش‌های دارای ارزش جایزه بالاتر در فهرست پیشنهادی بهتر قابل شناسایی و اولویت‌بندی خواهند بود.

چگونه از پاسخ‌دهی مجدد جلوگیری می‌شود؟

یکی از مسائل سیستم‌های پرسش و پاسخ، تکرار بی‌نهایت یک سؤال توسط یک کاربر است.

در ساختار متارنگ، برای جلوگیری از پاسخ‌دهی مجدد به سؤال پس از پاسخ اشتباه، شناسه سؤال برای همان کاربر در ساختار شرکت‌کننده قفل می‌شود.

به این ترتیب، مکانیزم قفل شناسه در کنار قوانین امتیازی به کاهش امکان تکرار بی‌نهایت سؤال کمک می‌کند.

چرخه عمر چالش چگونه پایان می‌یابد؟

هر چالش پس از رسیدن به یکی از شرایط زیر وارد وضعیت Archived (آرشیوشده) می‌شود:

پایان بودجه

تکمیل ظرفیت پاسخ‌دهی

رسیدن به زمان انقضا

نکته مهم این است که آرشیو به معنای حذف اطلاعات نیست.

اطلاعاتی مانند تعداد شرکت‌کنندگان، نسبت پاسخ‌های صحیح و غلط و میزان دارایی توزیع‌شده حفظ می‌شوند تا در تحلیل‌های بعدی و بررسی سابقه سیستم قابل استفاده باشند.

بخش ششم: خروجی نهایی چگونه تولید و کنترل کیفیت می‌شود؟

پس از استخراج دانش، تولید سؤال، اعتبارسنجی پاسخ و ثبت اطلاعات، نوبت به استانداردسازی خروجی می‌رسد.

در این مرحله، داده‌ها باید در قالبی قرار بگیرند که بتوان آن‌ها را در نوت‌بوک، پنل مدیریت و فرآیندهای آینده استفاده کرد.

هر سؤال چه ساختاری دارد؟

برای هر سؤال، مجموعه‌ای از فیلدهای مشخص در نظر گرفته شده است:

فیلد

کاربرد

شناسه یکتا

شناسایی مستقل سؤال

دسته تخصصی

تعیین حوزه دانش

منبع

مشخص کردن منشأ اطلاعات

محدوده نسخه

تعیین نسخه مرتبط

متن سؤال

محتوای پرسش

چهار گزینه

گزینه‌های قابل انتخاب

پاسخ صحیح

تعیین گزینه معتبر

سطح دشواری

طبقه‌بندی میزان دشواری

شناسه نویسنده

شناسایی تولیدکننده سؤال

نوع پاداش

مشخص کردن ساختار جایزه

اطلاعات تبلیغاتی

عنوان و لینک تبلیغ

برای شناسایی سؤال‌ها، ساختار شناسه‌ای مشابه نمونه زیر در نظر گرفته شده است:

Q-V1135-NET-001

این شناسه امکان شناسایی نسخه، حوزه تخصصی و شماره سؤال را فراهم می‌کند.

داده‌ها چگونه برای استفاده در سیستم استاندارد می‌شوند؟

Data Standardization (استانداردسازی داده) به معنای تبدیل اطلاعات به قالبی یکسان و قابل استفاده در بخش‌های مختلف سیستم است.

برای مثال، اگر سؤال‌ها در قالب‌های متفاوت ذخیره شوند، انتقال آن‌ها به پنل مدیریت یا پردازش خودکار دشوارتر خواهد شد.

به همین دلیل، پایپ‌لاین باید خروجی مشخص و یکپارچه‌ای تولید کند.

دو قالب اصلی برای این منظور در نظر گرفته شده است:

۱. Excel

این خروجی برای انتقال سؤال‌ها به سیستم مدیریت چالش استفاده می‌شود.

ستون‌های اصلی فایل شامل موارد زیر هستند:

ستون

محتوا

Question

متن سؤال

Opt1

گزینه اول

Opt2

گزینه دوم

Opt3

گزینه سوم

Opt4

گزینه چهارم

Answer

پاسخ صحیح

Author

نویسنده

Title_Ad

عنوان تبلیغ

Link_Ad

لینک تبلیغ

۲. JSON

قالب JSON (JavaScript Object Notation) یک ساختار متنی استاندارد برای تبادل داده میان نرم‌افزارهاست.

این قالب امکان انتقال اطلاعات سؤال‌ها به سرویس‌ها و ابزارهای نرم‌افزاری را فراهم می‌کند.

چگونه کیفیت سؤال‌ها کنترل می‌شود؟

تولید فایل Excel یا JSON پایان فرآیند نیست.

برای اطمینان از کیفیت بانک سؤال، یک مستند جداگانه برای داوران و مجمع علمی تهیه می‌شود.

در این مستند، منبع هر سؤال، دلیل صحت گزینه صحیح و ارجاع دقیق به سند، کامیت، تسک یا معماری مرتبط ثبت خواهد شد.

این کار امکان بررسی مستقل سؤال‌ها را فراهم می‌کند.

کنترل کیفیت فنی پایپ‌لاین چگونه انجام می‌شود؟

زیرساخت تولید سؤال نیز مانند سایر سرویس‌های نرم‌افزاری باید از چرخه توسعه و کنترل کیفیت عبور کند.

مراحل اصلی این فرآیند عبارت‌اند از:

توسعه در مخزن اختصاصی پروژه و برنچ تعیین‌شده، مطابق GitFlow یا Feature Branch

استقرار نسخه کاندید در محیط Staging یا Development Server

اجرای تست‌های پذیرش و Smoke Test

به‌روزرسانی README و مستندات اجرا، تست و متغیرهای محیطی

عبور از Quality Gate شامل Linting و تحلیل ایستا

بررسی آسیب‌پذیری‌های سورس‌کد و وابستگی‌ها

برقراری اتصال صحیح به Sentry برای ثبت و ردیابی خطاهای بحرانی

اجرای تست‌های خودکار برای منطق حیاتی سیستم

استفاده از رویکرد TDD در توسعه منطق اصلی

ادغام کد پس از تأیید تیم فنی یا ناظر و موفقیت Pipelineهای CI/CD

بررسی لاگ‌ها، خطاها و شاخص‌های مانیتورینگ پس از Merge

Quality Gate (دروازه کنترل کیفیت) مجموعه‌ای از معیارهای فنی است که کد باید پیش از عبور به مرحله بعدی توسعه، آن‌ها را رعایت کند.

همچنین CI/CD (یکپارچه‌سازی و تحویل یا استقرار پیوسته) به مجموعه فرآیندهای خودکار بررسی، ساخت، تست و انتشار نرم‌افزار اشاره دارد.

این کنترل‌ها کمک می‌کنند خطاهای منطقی، داده‌ای و امنیتی پیش از استفاده گسترده از سیستم شناسایی شوند.

نمودار چرخه تبدیل دانش به سؤال

فرآیند کلی پایپ‌لاین را می‌توان به شکل زیر خلاصه کرد:

مستندات رسمی متارنگ

↓

استخراج اطلاعات و گزاره‌های معتبر

↓

دسته‌بندی دانش در حوزه‌های تخصصی

↓

تولید سؤال و طراحی چهار گزینه

↓

اعتبارسنجی پاسخ صحیح و ثبت منبع

↓

استانداردسازی ساختار داده

↓

تولید خروجی Excel و JSON

↓

بررسی داوران و کنترل کیفیت فنی

↓

ورود به چرخه مدیریت چالش و آرشیو اطلاعات

جمع‌بندی: چرا این معماری اهمیت دارد؟

تبدیل مستندات پراکنده به یک بانک سؤال قابل استفاده، صرفاً به تولید چند پرسش و پاسخ محدود نمی‌شود.

این فرآیند به زیرساختی نیاز دارد که بتواند منشأ داده را حفظ کند، اطلاعات را در دسته‌های مشخص قرار دهد، سؤال‌های قابل ارزیابی تولید کند و صحت پاسخ‌ها را به منابع معتبر متصل نگه دارد.

در معماری متارنگ، نوت‌بوک Index Civilization Digital Metarang نقش مرکز سازماندهی این دانش را بر عهده دارد.

هدف، پوشش و سازماندهی ۳۶۹ سؤال موجود و ایجاد بستری برای تولید مستمر سؤالات جدید است.

ترکیب دسته‌بندی منابع، استانداردسازی داده، ارجاع‌پذیری پاسخ‌ها، مدیریت ظرفیت مالی، مکانیزم ضدتکرار، آرشیو اطلاعات و کنترل کیفیت فنی، چرخه‌ای قابل ردیابی برای مدیریت چالش‌ها ایجاد می‌کند.

در چنین ساختاری، هر سؤال تنها یک پرسش مسابقه‌ای نیست؛ بلکه یک واحد ساختاریافته از دانش مستند متارنگ است که می‌توان منشأ آن را بررسی کرد، صحت آن را سنجید و در فرآیندهای بعدی دوباره مورد استفاده قرار داد.

پرسش مهم‌تر این است: وقتی دانش یک اکوسیستم به داده‌های استاندارد و قابل ارزیابی تبدیل می‌شود، چه ظرفیت‌هایی برای توسعه آموزش، ارزیابی تخصص و مدیریت دانش در آن ایجاد خواهد شد؟

https://metarang.com/fa/articles/categories/algorithms/BL_10042

The redesign of Metarang’s logo can be seen as an effort to align the project’s visual language with the expanding dimensions of its activities. As Metarang’s scope has grown, its previous logo, built around a division of three primary colors, no longer reflected all the concepts the project sought to communicate within a single visual structure. The new version therefore takes a different approach, using a combination of visual elements to represent technology, strength, dynamism, creativity, and the relationship between humanity and the digital world.

But how are these concepts expressed through the structure of the new logo? To understand the design logic, we need to examine its main components individually.

The Titanium Frame: Representing Strength and Technological Infrastructure

One of the first elements that stands out in Metarang’s new logo is the polished metallic frame surrounding its central structure. Inspired by the visual characteristics of titanium, this frame incorporates patterns reminiscent of electronic circuits into its details.

Choosing a metallic structure is more than an aesthetic decision. Within the visual language of this logo, metal represents strength, order, and infrastructure. Its polished surface and precise form also help convey a professional, technology-driven image. Together, these features communicate concepts such as security, stability, and Metarang’s technological nature.

Another important detail is the presence of circuit-like patterns within the frame. Electronic circuits are widely recognized symbols of the technology world, and their inclusion makes the logo’s connection to digital infrastructure more apparent. In this sense, the metallic frame serves as the structural component of the symbol, bringing together the ideas of order, strength, and the project’s technological character.

In this way, the titanium frame establishes the first layer of meaning within the logo: a strong, organized infrastructure that reflects Metarang’s technology-driven identity.

The Fluid Glass Gem: A Core Representing Dynamism and Convergence

At the center of the new logo, the rigid, segmented form of the previous version has been replaced by a transparent glass core with a fluid structure. This is one of the most significant visual differences between the two versions.

The new form is designed as a glass-like gem in which colors dynamically blend, glow, and circulate. The transparency and fluid appearance of this core contrast with the metallic structure surrounding it, allowing the logo to communicate two distinct qualities at once: strength in its outer structure and dynamism at its center.

This combination is also meaningful from a conceptual perspective. The central core is intended to represent energy, creativity, and interaction among the different elements of Metarang’s identity. For this reason, the colors are not presented as completely separate sections. Instead, they blend together within a unified structure.

This combination ultimately converges into a luminous point at the center, reflecting the unity and convergence of technology, humanity, creativity, and the digital economy within a single structure.

Therefore, the glass gem is more than just the colorful part of the logo. It is the central element through which dynamism and the relationships among different aspects of the brand’s identity are expressed.

The Language of Color: Six Hues Expressing Identity

Colors in Metarang’s new logo are not merely decorative or aesthetic choices. Each color spectrum is associated with a specific concept, and their combination within the central core creates a multidimensional representation of the project’s identity.

In this design, the color spectrum can be examined through three conceptual groups:

1. Red and Pink: Human Energy and Dynamism

Red and pink represent passion, energy, and human dynamism. Their presence in the central structure emphasizes the role of people and the energy generated through their interaction with the digital world. This part of the color palette reflects the human and dynamic dimension of Metarang’s identity.

2. Yellow and Green: Growth and Development

Yellow and green are associated with concepts such as hope, freshness, and growth. This spectrum represents the development of ideas and the expansion of the ecosystem. In effect, these colors symbolize movement, the emergence of new ideas, and Metarang’s vision for future development.

3. Blue and Purple: Technology and the Digital World

Blue and purple refer to technology, the depth of the metaverse, and artificial intelligence. These colors establish a more direct connection with the digital environment and the project’s technological nature, completing the technological dimension of its visual identity alongside the other hues.

The significance of this combination lies in the way the colors interact. None of them represents Metarang’s entire identity on its own. Their meaning emerges from their arrangement and movement toward the luminous central point, where human energy, growth, technology, and creativity come together in a single visual symbol.

Persian and English Naming: Preserving Identity While Embracing an International Vision

A brand’s identity is not communicated solely through its visual symbol. Its name, typography, and presentation also play an important role in shaping the audience’s visual experience.

At the bottom of the new logo, the Persian name «متارنگ» appears in modern Persian typography alongside the English name METARANG. This choice brings together two dimensions of the project’s identity.

The Persian name emphasizes Metarang’s linguistic and cultural roots, while the simultaneous use of its English name reflects its international outlook and presence in the global technology and digital economy landscape.

This bilingual combination ensures that Metarang’s visual identity is not limited to a single language or audience. It preserves its Persian identity while also creating opportunities to connect with international audiences.

Alongside these two names, a custom M monogram is used as another element of the brand identity. Focusing on the first letter of Metarang’s English name, the monogram creates an independent typographic symbol alongside the main emblem and bilingual wordmark.

The M Monogram: Completing the Brand Identity Structure

Monograms typically simplify a brand’s name into a recognizable typographic symbol, allowing its identity to be presented independently.

In Metarang’s new visual identity, the letter M serves as a custom monogram alongside the main logo structure. Its presence next to the Persian and English names brings together a collection of typographic and visual elements within a unified identity.

In this composition, the central symbol, bilingual name, and M monogram each serve different purposes. Together, however, they contribute to the recognition and consistency of the brand.

How Do Different Elements Create a Unified Visual Identity?

To better understand Metarang’s new logo, it is important to consider the relationships between its components rather than focusing only on the individual characteristics of each one.

The metallic frame and circuit-inspired patterns communicate structure, strength, and technological character. The fluid glass core represents dynamism and the connections between different elements. The color spectrum brings together concepts such as human energy, growth, technology, and artificial intelligence at a central point.

In the typographic section, the Persian and English names appear alongside the M monogram, bringing the project’s roots and international vision together within a coordinated structure.

What connects these elements is the division of roles among structure, content, and identity: the frame establishes the visual framework; the glass core creates a dynamic inner space; the colors communicate meaning; and the typographic elements reinforce the identity of the Metarang name.

From this perspective, the redesign of Metarang’s logo can be understood as an effort to transform a collection of technological and human concepts into a coherent visual language. This language is intended to be used across different parts of the Metarang ecosystem, helping establish a unified image of the project.

Ultimately, Metarang’s new visual identity demonstrates how logo design can go beyond the selection of shapes and colors. When material, structure, color, and typography are brought together with a clear purpose, a logo becomes a tool for communicating a project’s concepts and vision. In Metarang’s new identity, these concepts take shape through the connection between technology, humanity, creativity, and the digital world.

به سوی بی‌نهایت؛ رونمایی از هویت بصری جدید و متحول‌شده متارنگ

طراحی یک لوگو زمانی از سطح یک نشانه گرافیکی فراتر می‌رود که عناصر بصری آن بتوانند مفاهیم و ویژگی‌های یک پروژه را به مخاطب منتقل کنند. انتخاب جنس، فرم، رنگ و حتی نحوه نمایش نام یک مجموعه، همگی در ساخت تصویری منسجم از هویت آن نقش دارند. در هویت بصری جدید متارنگ نیز این عناصر در کنار یکدیگر قرار گرفته‌اند تا تصویری متناسب با مسیر توسعه این پروژه در حوزه فناوری، متاورس، هوش مصنوعی و خلاقیت دیجیتال ارائه دهند.

بازطراحی لوگوی متارنگ را می‌توان تلاشی برای هماهنگ‌کردن زبان بصری این پروژه با ابعاد جدید فعالیت‌های آن دانست. با گسترش دامنه فعالیت متارنگ، نشانه پیشین که بر پایه تقسیم‌بندی سه رنگ اصلی شکل گرفته بود، دیگر تمام مفاهیم موردنظر این پروژه را در قالب یک ساختار بصری واحد بازتاب نمی‌داد. به همین دلیل، در نسخه جدید تلاش شده است فناوری، استحکام، پویایی، خلاقیت و ارتباط میان انسان و جهان دیجیتال با ترکیبی متفاوت از عناصر بصری نمایش داده شوند.

اما این مفاهیم چگونه در ساختار لوگوی جدید شکل گرفته‌اند؟ برای درک منطق طراحی، باید اجزای اصلی آن را جداگانه بررسی کرد.

فریم تیتانیومی؛ نمایش استحکام و زیرساخت فناوری

یکی از نخستین عناصر قابل‌توجه در لوگوی جدید متارنگ، فریم فلزی و صیقلی پیرامون ساختار مرکزی است. این فریم با الهام از ویژگی‌های بصری تیتانیوم طراحی شده و الگوهای مدارهای الکترونیکی را در جزئیات خود جای داده است.

انتخاب یک ساختار فلزی، صرفاً یک تصمیم زیبایی‌شناختی نیست. در زبان بصری این لوگو، فلز نماینده استحکام، نظم و زیرساخت است. سطح صیقلی و فرم منظم آن نیز به انتقال تصویری حرفه‌ای و فناورانه کمک می‌کند. این ویژگی‌ها در کنار یکدیگر، مفاهیمی مانند امنیت، ثبات و ماهیت تکنولوژیک متارنگ را به مخاطب منتقل می‌کنند.

نکته مهم دیگر، حضور الگوهای مدارگونه در ساختار فریم است. مدارهای الکترونیکی از نشانه‌های شناخته‌شده جهان فناوری هستند و حضور آن‌ها باعث می‌شود ارتباط لوگو با زیرساخت‌های دیجیتال واضح‌تر شود. در واقع، فریم فلزی نقش بخش ساختاری نشانه را بر عهده دارد؛ بخشی که مفهوم نظم و استحکام را در کنار ماهیت فناورانه پروژه قرار می‌دهد.

به این ترتیب، فریم تیتانیومی نخستین لایه معنایی لوگو را شکل می‌دهد: زیرساختی منظم و مستحکم که هویت فناوری‌محور متارنگ را بازتاب می‌دهد.

گوهر شیشه‌ای و سیال؛ هسته‌ای برای نمایش پویایی و همگرایی

در مرکز لوگوی جدید، به‌جای فرم سخت و تفکیک‌شده نسخه پیشین، یک هسته شیشه‌ای و شفاف با ساختاری سیال قرار گرفته است. این بخش از طراحی، یکی از مهم‌ترین تفاوت‌های بصری دو نسخه محسوب می‌شود.

فرم جدید به شکل یک گوهر شیشه‌ای طراحی شده که رنگ‌ها درون آن به‌صورت پویا، درخشان و چرخان با یکدیگر ترکیب می‌شوند. شفافیت و جلوه سیال این هسته، در تقابل با ساختار فلزی پیرامون آن قرار می‌گیرد؛ به‌گونه‌ای که لوگو هم‌زمان دو ویژگی متفاوت را نمایش می‌دهد: استحکام در ساختار بیرونی و پویایی در بخش مرکزی.

این ترکیب از نظر معنایی نیز اهمیت دارد. هسته مرکزی قرار است محل نمایش انرژی، خلاقیت و تعامل میان عناصر مختلف هویت متارنگ باشد. به همین دلیل، رنگ‌ها به شکل بخش‌هایی کاملاً جدا از یکدیگر نمایش داده نشده‌اند، بلکه در یک ساختار واحد با هم ترکیب می‌شوند.

این ترکیب در مرکز به نقطه‌ای نورانی منتهی می‌شود؛ نقطه‌ای که مفهوم اتحاد و همگرایی فناوری، انسان، خلاقیت و اقتصاد دیجیتال را در یک ساختار واحد بازتاب می‌دهد.

بنابراین، گوهر شیشه‌ای صرفاً بخش رنگی لوگو نیست؛ بلکه هسته‌ای است که پویایی و ارتباط میان مفاهیم مختلف هویتی را به نمایش می‌گذارد.

زبان رنگ‌ها؛ شش طیف برای بیان مفاهیم هویتی

رنگ‌ها در لوگوی جدید متارنگ نقش تزئینی و صرفاً زیبایی‌شناختی ندارند. هر طیف رنگی با مفهوم مشخصی ارتباط دارد و ترکیب آن‌ها در هسته مرکزی، تصویری چندوجهی از هویت پروژه ایجاد می‌کند.

در این طراحی، طیف‌های رنگی در سه گروه مفهومی قابل بررسی هستند:

۱. قرمز و صورتی؛ انرژی و پویایی انسانی

طیف قرمز و صورتی بیانگر شور، انرژی و پویایی انسانی است. حضور این رنگ‌ها در ساختار مرکزی، بر نقش انسان و انرژی حاصل از تعامل او با جهان دیجیتال تأکید می‌کند. این بخش از پالت رنگی، وجه انسانی و پرتحرک هویت متارنگ را بازتاب می‌دهد.

۲. زرد و سبز؛ رشد و توسعه

رنگ‌های زرد و سبز با مفاهیمی مانند امید، تازگی و رشد ارتباط دارند. این طیف، بیانگر توسعه ایده‌ها و گسترش اکوسیستم است. در واقع، این رنگ‌ها بخش مرتبط با حرکت، شکل‌گیری ایده‌های تازه و چشم‌انداز توسعه متارنگ را در هویت بصری آن نمایندگی می‌کنند.

۳. آبی و بنفش؛ فناوری و جهان دیجیتال

طیف آبی و بنفش به فناوری، عمق جهان متاورس و هوش مصنوعی اشاره دارد. این رنگ‌ها ارتباط مستقیم‌تری با فضای دیجیتال و ماهیت فناورانه پروژه برقرار می‌کنند و در کنار سایر طیف‌ها، بُعد تکنولوژیک هویت بصری را کامل می‌سازند.

اهمیت این ترکیب در نحوه هم‌نشینی رنگ‌هاست. هیچ‌کدام به‌تنهایی تمام هویت متارنگ را نمایندگی نمی‌کنند. معنا از کنار هم قرار گرفتن آن‌ها و حرکتشان به سمت نقطه نورانی مرکزی شکل می‌گیرد؛ جایی که انرژی انسانی، رشد، فناوری و خلاقیت در یک نشانه بصری به هم می‌رسند.

نام فارسی و انگلیسی؛ حفظ ریشه هویتی در کنار چشم‌انداز بین‌المللی

هویت یک برند فقط از طریق نماد تصویری آن منتقل نمی‌شود. نام، شیوه نوشتار و نحوه نمایش آن نیز بخش مهمی از تجربه بصری مخاطب را شکل می‌دهند.

در بخش پایینی لوگوی جدید، نام «متارنگ» با تایپوگرافی فارسی مدرن در کنار نام انگلیسی METARANG قرار گرفته است. این انتخاب، دو جنبه از هویت پروژه را در کنار یکدیگر حفظ می‌کند.

نمایش نام فارسی، بر ریشه زبانی و هویتی متارنگ تأکید دارد؛ درحالی‌که استفاده هم‌زمان از نام انگلیسی، چشم‌انداز بین‌المللی و حضور این پروژه در فضای جهانی فناوری و اقتصاد دیجیتال را بازتاب می‌دهد.

این ترکیب دو‌زبانه باعث می‌شود هویت بصری متارنگ به یک زبان یا فضای مخاطب محدود نشود و در عین حفظ هویت فارسی، امکان ارتباط با مخاطبان بین‌المللی را نیز در ساختار خود داشته باشد.

در کنار این دو نام، مونوگرام اختصاصی M نیز به‌عنوان یکی دیگر از عناصر هویتی در لوگو استفاده شده است. مونوگرام با تمرکز بر حرف نخست نام انگلیسی متارنگ، یک نشانه نوشتاری مستقل در کنار نماد اصلی و تایپوگرافی دو‌زبانه ایجاد می‌کند.

مونوگرام M؛ تکمیل ساختار نشانه هویتی

مونوگرام‌ها معمولاً با ساده‌سازی نام یک برند به یک نشانه نوشتاری قابل‌شناسایی، امکان نمایش هویت آن را در قالبی مستقل فراهم می‌کنند.

در هویت بصری جدید متارنگ، حرف M به‌عنوان مونوگرام اختصاصی در کنار ساختار اصلی لوگو قرار گرفته است. حضور این عنصر در کنار نام فارسی و انگلیسی، مجموعه‌ای از نشانه‌های نوشتاری و تصویری را در یک هویت واحد گرد هم می‌آورد.

در این ترکیب، نماد مرکزی، نام دو‌زبانه و مونوگرام M نقش‌های متفاوتی دارند؛ اما در کنار یکدیگر به شناسایی و انسجام هویت برند کمک می‌کنند.

چگونه اجزای مختلف، یک هویت بصری واحد می‌سازند؟

برای درک بهتر لوگوی جدید متارنگ، باید به ارتباط میان اجزای آن توجه کرد، نه صرفاً ویژگی‌های جداگانه هر بخش.

فریم فلزی و الگوهای مدارگونه، ساختار، استحکام و ماهیت فناورانه را نمایش می‌دهند. هسته شیشه‌ای و سیال، پویایی و ارتباط میان عناصر مختلف را به تصویر می‌کشد. طیف‌های رنگی نیز مفاهیم انرژی انسانی، رشد، فناوری و هوش مصنوعی را در یک نقطه مرکزی به هم پیوند می‌دهند.

در بخش نوشتاری، نام فارسی و انگلیسی در کنار مونوگرام M قرار گرفته‌اند تا ریشه هویتی و چشم‌انداز بین‌المللی پروژه در یک ساختار هماهنگ حضور داشته باشند.

آنچه این اجزا را به یکدیگر مرتبط می‌کند، تقسیم نقش میان ساختار، محتوا و هویت است: فریم، چارچوب بصری را می‌سازد؛ هسته شیشه‌ای، فضای پویای درونی را شکل می‌دهد؛ رنگ‌ها، مفاهیم را منتقل می‌کنند و عناصر نوشتاری، هویت نام متارنگ را تثبیت می‌کنند.

از این منظر، بازطراحی لوگوی متارنگ را می‌توان تلاشی برای تبدیل مجموعه‌ای از مفاهیم فناورانه و انسانی به یک زبان بصری منسجم دانست؛ زبانی که قرار است در نقاط مختلف اکوسیستم متارنگ مورد استفاده قرار گیرد و زمینه شکل‌گیری یک تصویر واحد از این پروژه را فراهم کند.

در نهایت، هویت بصری جدید متارنگ نشان می‌دهد که طراحی یک نشانه می‌تواند فراتر از انتخاب فرم و رنگ باشد. زمانی که جنس، ساختار، رنگ و نوشتار با هدف مشخصی کنار یکدیگر قرار می‌گیرند، لوگو به ابزاری برای بیان مفاهیم و چشم‌انداز یک پروژه تبدیل می‌شود؛ مفاهیمی که در هویت جدید متارنگ، در پیوند میان فناوری، انسان، خلاقیت و جهان دیجیتال شکل گرفته‌اند.

https://metarang.com/fa/news/categories/technology-and-infrastructure-development/news_10022