Kayan Academy

🔥 مش أي Section في Revit ينفع لكل حاجة… والغلطة هنا بتكلفك وقت ومجهود!

كتير بيستخدموا Sections عشوائي، والنتيجة؟
الـViews زيادة، لوحات ملخبطة، وموديل تقيل من غير سبب.
خلّيك ذكي… واختار النوع الصح 👇

1️⃣ الـ Section الحقيقي (The Real Deal)
ده قطاع فعلي وView كامل الصلاحيات.
📍 بيظهر في:
🔹 Project Browser
🔹 Sheets
🛠️ تستخدمه في:
🔹 التنفيذ
🔹 التفاصيل
🔹 الأبعاد (Dimensions)
🔹 الـ Annotations
🔹 تسليم اللوحات
💪 ليه هو مهم؟
✔ تعدّل الموديل مباشرة
✔ تشتغل عليه Detailing كامل
✔ أساس أي تسليم محترم
📌 إنشاءه: View → Create → Section

2️⃣ الـ Reference Section (الذكي الهادي)
ده مش View
ولا بيعمل قطاع جديد.
اعتبره: 👉 سهم بيرشد القارئ لرسمة موجودة أصلًا
🎯 وظيفته:
🔹 ربط الرسومات ببعض
🔹 الإشارة لتفصيلة أو قطاع تاني
🔹 تنظيم اللوحات من غير تكرار
✨ مميزاته:
✔ مفيش Views زيادة
✔ Project أنضف
✔ تنظيم احترافي
📌 إنشاءه: View → Section → Reference Other View
وبتختار الـ View اللي عايز تشير له.
💡 أفضل استخدام: لما يكون عندك قطاع جاهز، وعايز تشير له من مكان تاني من غير ما تكرر الشغل.

3️⃣ الـ Section Box (الفهم الحقيقي في 3D)
ده قطاع… بس جوه 3D View.
👀 يفيدك في:
🔹 عزل جزء من المبنى
🔹 فهم العلاقات بين العناصر
🔹 التعديل وانت شايف العمق الحقيقي
⚙️ تفعّله إزاي؟
من 3D View فعّل Section Box
أو
Select Element → Modify → View → Section Box
Shortcut: BX
وبعدها تتحكم في حدود الـ Box زي ما تحب.

⚡ الخلاصة اللي تفرق المحترف عن غيره
🔹الـSection ← تنفيذ وتسليم
🔹 الـReference Section ← تنظيم وربط
🔹 الـSection Box ← فهم وتحكّم ثلاثي الأبعاد

🚫 المحترف مش اللي يعمل Sections كتير
✅ المحترف هو اللي يستخدم النوع الصح في المكان الصح
لو فهمت النقطة دي…Revit هيشتغل معاك مش ضدك 👌

🚨 مش كل Automation في Revit محتاج C # وVisual Studio… ساعات الحل الذكي مش أقوى كود، الحل الذكي هو الأداة المناسبة للمشكلة.

لو داخل مجال BIM Development أو Design Automation، طبيعي تسأل:
هل لازم أتعلم C # علشان أتعامل مع Revit API؟
وهل لو اتعلمتها أعتمد عليها في كل حاجة؟

الإجابة:
الـ C # مهمة جدًا، لكن مش هي الحل الأنسب لكل حالة.
في Revit Automation عندك أكتر من طريق، وكل طريق له مكانه.

1️⃣ Dynamo
ده Visual Programming عن طريق Nodes.
مناسب جدًا للمهام السريعة والمتكررة، خصوصًا لو محتاج تعمل Automation من غير ما تدخل في كود معقد.
♦️ مميزاته:
✔ سهل نسبيًا للمبتدئين
✔ مناسب للـ One-shot Tasks
✔ فيه Community كبير
✔ تقدر تدعم الـ Workflow بكود Python عند الحاجة
📌 لو عندك مهمة سريعة في مشروع شغال، Dynamo غالبًا هيكون أسرع حل.

2️⃣ pyRevit
ده ممتاز للـ Scripting باستخدام Python.
تقدر تعمل Scripts سريعة وتحولها لأزرار داخل Ribbon في Revit،
من غير Compile ولا إعدادات Add-in معقدة.
♦️ مناسب لما:
✔ الـ Dynamo بقى بطيء
✔ الـ Nodes بقت معقدة
✔ محتاج Tool تتكرر يوميًا
✔ عايز Deploy سريع للفريق
📌 الـ pyRevit منطقة قوية جدًا بين الحلول السريعة والـ Add-ins الكبيرة.

3️⃣ Revit Macros
دي بيئة مدمجة جوه Revit لكتابة وتشغيل كود مباشرة.
ممكن تستخدم فيها C # أو VB.NET،
وغالبًا بتكون مناسبة للمهام الخاصة بمشروع معين.
♦️ مناسبة لما:
✔ عندك Task خاصة بمشروع واحد
✔ محتاج كود سريع داخل الملف
✔ الأداة مش هتتحول لمنتج عام
✔ مش محتاج Packaging كامل
📌 الـ Macros حل عملي، لكن مش دايمًا مناسب كأداة طويلة العمر أو سهلة التوزيع.

4️⃣ Compiled Add-ins
ده طريق الـ C # / .NET / Visual Studio / Revit API SDK.
أقوى طريق من ناحية التحكم، لكنه كمان الأكثر احتياجًا لفهم برمجة حقيقي.
♦️ مناسب لما تبني:
✔ الـ Product تجاري
✔ الـ Tool للشركة كلها
✔ الـ UI متقدمة باستخدام WPF
✔ معالجة Geometry أو Data تقيلة
✔ أدوات تحتاج Performance عالي
✔ حلول قابلة للتوزيع والصيانة
📌 هنا لازم تكون فاهم C # وOOP وRevit API بشكل عميق.

♦️ طيب أتعلم إيه؟
اللغات الأكثر استخدامًا مع Revit API:
- C #
- Python
- VB.NET
الـ Python غالبًا هتستخدمها مع Dynamo أو pyRevit.
الـ C # وVB.NET غالبًا مع Macros أو Compiled Add-ins.
ومش لازم تبدأ بأصعب طريق.
ابدأ حسب نوع المشكلة وحجمها.

♦️ تختار إيه بسرعة؟

🔹لو Task سريعة لمرة واحدة؟
استخدم Dynamo

🔹لو Tool متكرر وخفيف للفريق؟
استخدم pyRevit

🔹لو Task خاصة بمشروع معين؟
استخدم Macros

🔹لو Product قوي وقابل للتوزيع؟
استخدم C # Add-in

♦️ الخلاصة
الـ Automation مش سباق مين يكتب كود أعقد.
الـ Automation الصح هو إنك تختار أقل حل يحقق الهدف بأعلى كفاءة.

ما تستخدمش C # علشان تثبت إنك Developer…
استخدم C # لما المشكلة فعلًا تستاهل C #.

من محاضرات BIM Management Diploma

🚨 اختيار لون الواجهة مش قرار ديكور… ده قرار طاقة وحرارة وراحة بصرية.

في مشاريع كتير، لون الواجهة بيتاخد بناءً على الذوق أو الـ Branding فقط.
لكن في الحقيقة، اللون بيأثر مباشرة على:
- حرارة المبنى
- دخول الإضاءة الطبيعية
- استهلاك التكييف
- الراحة البصرية داخل الفراغات
وهنا بيظهر مصطلح مهم جدًا:
LRV – Light Reflectance Value

♦️ يعني إيه LRV؟
هو ببساطة نسبة الضوء اللي السطح بيعكسها.

🔹 0%
سطح غامق جدًا، بيمتص أغلب الضوء والحرارة.

🔹 100%
سطح فاتح جدًا، بيعكس أغلب الضوء.

يعني كل ما قيمة الـ LRV تعلى،
السطح يعكس ضوء أكتر ويمتص حرارة أقل.

♦️ مثال تصميمي بسيط
لو عندك واجهة مبنى إداري:
- الأسطح الرئيسية بقيمة LRV حوالي 70
- الفريمات والتفاصيل بقيمة LRV حوالي 20
النتيجة ممكن تكون:
✔ تقليل Heat Gain على الواجهة
✔ تحسين Daylighting داخل الفراغات
✔ تقليل حمل التكييف
✔ إبراز التفاصيل المعمارية بذكاء
✔ توازن بين الشكل والأداء

♦️ نجيب قيمة LRV منين؟
الأدق دائمًا هو:
Manufacturer Datasheets
شركات الدهانات، الأحجار، الألومنيوم، والمواد النهائية غالبًا بتوفر LRV لكل لون أو Finish.

وفيه أدوات ممكن تساعدك في التقدير، زي:
- Revit
- Photoshop
- RGB Analysis
لكن خلي بالك:
دي تقديرات، مش بديل عن الداتا الرسمية من المصنع.

♦️ نقطة مهمة من الواقع
نفس اللون ممكن يدي LRV مختلف حسب:
- نوع الخامة
-الـ Matte ولا Glossy
-الـ Texture
-الـ Roughness
- طريقة التشطيب
- انعكاس السطح
يعني مش كل رمادي زي بعض، ومش كل بيج هيقدّم نفس الأداء.

♦️ ليه LRV مهم؟
لأنه بيربط بين:
✔ Facade Design
✔ Thermal Performance
✔ Energy Efficiency
✔ Visual Comfort
✔ Sustainability
وده الفرق بين واجهة شكلها حلو فقط،
وواجهة شكلها حلو وبتشتغل بذكاء.

♦️ الخلاصة
اللون في الواجهات مش مجرد اختيار بصري.
ده عامل مؤثر في أداء المبنى وتشغيله على المدى الطويل.

المصمم الذكي مش بيختار لون وخلاص…
هو بيختار أداء مغلف في شكل جميل.

🚨 لو مش فاهم مراحل المشروع… هتستغرب ليه الاستشاري ما طلعش كل التفاصيل من أول يوم، وليه المقاول بيطلب Shop Drawings بعد IFC.

في أي مشروع Construction، كل مرحلة ليها هدف وحدود ومخرجات.
ومش طبيعي إن كل التفاصيل تظهر من أول مرحلة، لأن كل مرحلة ليها Scope وتكلفة وتعاقد مختلف.
خلينا نرتبها ببساطة 👇

1️⃣ BODR
Basis of Design Report
ده تقرير الأساس التصميمي للمشروع.
بيوضح:
- الأكواد المستخدمة
- المعايير والـ Standards
- الفرضيات التصميمية
- القيم الأساسية للحسابات
- متطلبات الأنظمة
- أسس اختيار المعدات
وبعد اعتماد المالك له، أي تغيير جوهري بعده ممكن يتحول لـ Variation حسب التعاقد.

2️⃣ SD
Schematic Design
دي مرحلة الرسومات المبدئية.
بنحوّل أفكار ومبادئ الـ BODR إلى Layouts أولية،
لكن التفاصيل لسه محدودة.
🔹 مثال:
توزيع مبدئي للمسارات الرئيسية، الزونات، غرف الخدمات، وأماكن الأنظمة الأساسية.

3️⃣ DD
Detailed Design
هنا التصميم يبدأ يدخل في تفاصيل فعلية.
بيتم تطوير الرسومات بإضافة:
- مقاسات حقيقية
- حسابات أوضح
- توزيع أدق للعناصر
- مسارات وخطوط فرعية
- تفاصيل تصميمية أكبر
🔹 مثال في الفاير:
توزيع الرشاشات، البرانشات، الأحجام، والحسابات.

4️⃣ TD
Tender Drawings
دي مرحلة الطرح للمقاولين.
المقاول يستلم المستندات علشان يدرس المشروع ويقدم عرضه الفني والمالي.
ومن أهم مخرجات المرحلة:
- Tender Drawings
- Specifications
- BOQ
- Vendor List
- شروط عامة وخاصة
- مستندات المناقصة
الهدف هنا إن المقاولين يسعروا على أساس واضح وعادل.

5️⃣ IFA
Issued for Approval
دي الرسومات والمستندات اللي بتتقدم للجهات المختصة للاعتماد.
زي:
- البلدية
- الدفاع المدني
- الجهات التنظيمية
- المالك أو الاستشاري حسب نظام المشروع

6️⃣ IFC
Issued for Construction
دي الرسومات المعتمدة للتنفيذ.
بعد ما تاخد الاعتمادات المطلوبة، بتتحول لمرجع تنفيذي للمقاول.
وغالبًا هنا التفاصيل تكون وصلت لأعلى مستوى تصميمي قبل مرحلة الـ Shop Drawings.
📌 ملحوظة:
المقصود هنا IFC = Issued for Construction، مش IFC File Format الخاص بالـ BIM.

7️⃣ SHD
Shop Drawings
دي مرحلة المقاول.
المقاول يحوّل رسومات الـ IFC إلى لوحات تنفيذية أكثر تفصيلًا، تشمل:
- تفاصيل التركيب
- Supports
- Hangers
- Sleeves
- Welding Details
- Accessories
- Dimensions
- Levels
- Equipment Data حسب الكتالوجات المعتمدة
- Take-off Schedules
وبعدها تتقدم للاعتماد من الاستشاري.

8️⃣ ASB
As-Built
دي المرحلة الأخيرة.
اللوحات هنا بتوثق ما تم تنفيذه فعليًا في الموقع.
وممكن تختلف عن الـ Shop Drawings حسب ظروف التنفيذ،
لكن لازم تكون معتمدة ومحدثة بدقة.
وده بيكون مرجع مهم للمالك وفريق التشغيل والصيانة.

🔹 في النهاية
المشروع لازم يتسلم ومعاه كل الملفات المهمة، زي:
- As-Built Drawings
- Catalogues
- O&M Manuals
- Approved Submittals
- Warranties
- Purchase Documents
- Contracts
- Final Reports

♦️ الخلاصة
كل مرحلة في المشروع ليها معنى، ومش مطلوب من مرحلة إنها تعمل شغل مرحلة تانية.
يعني :
الـ SD يوضح الفكرة،
الـ DD يطوّر التصميم،
الـ Tender يفتح التسعير،
الـ IFC يجهز التنفيذ،
الـ Shop Drawings يشرح طريقة التنفيذ،
وAs-Built يوثق الواقع بعد التنفيذ.

كل المحاضرات الموضحة تأتي ضمن منظومة كيان التدريبية ✨
نحن لا نقدم محتوى تدريبي فقط، بل نصنع بيئة تعليمية تجمع بين الخبرة، التطبيق العملي، والإبداع.

انضم لفريق كيان وكن جزءًا من رحلة التطوير والتميز 🚀

🚨 في ISO 19650، لقبك الوظيفي مش هو الأهم… الأهم هو دورك في رحلة المعلومة داخل المشروع.

الـ BIM مش مجرد موديل ثلاثي الأبعاد.
هو نظام لإدارة المعلومات، المسؤوليات، الاعتمادات، والتسليمات.
وعلشان كده ISO 19650 ما بيعرّفش الأطراف بأسمائهم التقليدية بس،
لكن بيعرّفهم حسب مسؤوليتهم في إنتاج وتبادل واعتماد المعلومات.
خلينا نبسط الأدوار الأساسية 👇

1️⃣ Appointing Party
ده غالبًا بيكون:
Owner / Client / Asset Owner / Operator
وده الطرف اللي بيحدد هو محتاج إيه من معلومات.
مسؤول عن:
✔ إصدار الـ EIR
✔ تحديد متطلبات المعلومات
✔ تحديد أهداف المشروع أو الأصل
✔ اعتماد الـ CDE
✔ مراجعة واعتماد المعلومات المستلمة
يعني هو الطرف اللي بيقول:
“أنا محتاج إيه، ليه، وإمتى.”

2️⃣ Lead Appointed Party
ده غالبًا بيكون:
Main Contractor / Lead Consultant
وده الطرف المسؤول عن إدارة وتنسيق إنتاج المعلومات بين باقي الفرق.
مسؤول عن:
✔ إعداد وتنفيذ الـ BEP
✔ تنسيق تبادل المعلومات
✔ متابعة الـ Revisions وحالات المستندات
✔ التأكد من الالتزام بالـ Naming Convention
✔ ضبط طريقة التسليم طبقًا لمتطلبات المشروع
يعني هو حلقة الوصل الرئيسية بين المالك وباقي الأطراف.

3️⃣ Appointed Party
ده ممكن يكون:
Subcontractor / Discipline Consultant / Specialist Team
وده الطرف اللي بينتج جزء محدد من معلومات المشروع.
مسؤول عن:
✔ إنتاج النماذج والوثائق
✔ الالتزام بالـ EIR والـ BEP
✔ رفع الملفات على الـ CDE بالحالة الصحيحة
✔ تطبيق الـ Metadata والتسمية والتصنيف
✔ تسليم معلومات تخصصه في الوقت المطلوب
يعني هو مصدر البيانات التخصصية داخل المشروع.

4️⃣ Appointment
ده مش شخص.
ده الإطار أو الاتفاق اللي بيحدد مسؤوليات المعلومات بين الأطراف.
وبيوضح:
✔ مين مسؤول عن إيه؟
✔ إيه المطلوب تسليمه؟
✔ إمتى يتسلم؟
✔ إزاي تتم المراجعة والاعتماد؟
✔ مين له صلاحية الوصول داخل الـ CDE؟

♦️ الخلاصة
الـ ISO 19650 بيخلينا نبص للـ BIM كمنظومة معلومات، مش مجرد برنامج أو موديل.

نجاح BIM Management مش بيبدأ من Revit أو Navisworks…
بيبدأ من وضوح الأدوار، ومسار المعلومة، ومسؤولية كل طرف داخل المشروع.

🚨 أخطر Clash في المشروع مش اللي ظاهر بالأحمر في Navisworks… أخطر Clash هو اللي الموديل ساكت عنه والموقع هيكشفه بعدين.

في شغل الـ BIM Coordination، ناس كتير بتتعامل مع الـ Clashes كأنها نوع واحد:
عنصر داخل في عنصر… نعدله وخلاص.
لكن الحقيقة إن الـ Clash له أنواع،
ولو ما فرّقتش بينهم، اجتماعات التنسيق هتتحول لكلام كتير من غير حل حقيقي.
خلينا نقسمها ببساطة 👇

1️⃣ Hard Clash
ده النوع الواضح والمباشر.
عنصرين متداخلين فعليًا في بعض.
🔹 مثال:
-الـ Duct داخل Beam
-الـ Pipe داخل Column
-الـ Cable Tray قاطع Wall بدون Opening
وده غالبًا أسهل نوع الـ Software يكتشفه.
لكن المشكلة إن ناس كتير بتقف عنده وتفتكر إن كده التنسيق خلص.

2️⃣ Soft Clash
هنا العناصر مش داخلة في بعض، لكن المسافة بينهم مش كفاية.
يعني الموديل ممكن يبان سليم، لكن في التنفيذ أو التشغيل هتظهر المشكلة.
🔹 مثال:
- الـ Valve مفيش حواليها مساحة صيانة
- الـ Electrical Panel الباب بتاعه مش هيفتح بالكامل
- الـ AHU أو Chiller مفيش Access للفك أو الصيانة
- الـ Pipe قريب جدًا من عنصر تاني ومفيش Insulation Clearance
وده نوع خطير لأنه مش دايمًا بيبان كـ Clash صريح.

3️⃣ Workflow Clash
وده في رأيي أخطر نوع.
العناصر كلها ممكن تكون سليمة هندسيًا، والمسافات ممكن تكون مقبولة، لكن ترتيب التنفيذ نفسه مش منطقي.
🔹 مثال:
- الـ Cable Tray لازم يتركب قبل Duct، لكن بعد تركيب الدكت مفيش Access للتركيب
- الـ Pipe Welding محتاج مساحة عمل، لكنها هتتقفل بعد تركيب عنصر تاني
- معدة محتاجة تدخل قبل غلق فتحة أو تركيب حائط
- عنصر قابل للصيانة، لكن بعد التشطيب الوصول له شبه مستحيل
النوع ده الـ Software غالبًا مش هيشوفه.
ده محتاج BIM Coordinator فاهم موقع وتنفيذ، مش مجرد مستخدم Tool.

♦️ الخلاصة
الـ BIM Coordination الحقيقي مش مجرد إن عدد الـ Clashes يبقى صفر.
لازم تسأل:
✔ هل فيه Clearance كافي؟
✔ هل العنصر قابل للصيانة؟
✔ هل ترتيب التنفيذ منطقي؟
✔ هل فيه Access للتركيب؟
✔ هل المشكلة اتحلت فعلًا، ولا اختفت من الموديل بس؟

الـ Clash Detection بيكشف التداخلات…
لكن خبرة المهندس هي اللي تكشف هل الحل قابل للتنفيذ ولا مجرد شكل نظيف في الموديل.