• Advertisement
  • Popular Tags

  • Popular Now

  • Advertisement
  • Similar Content

    • By jhocking
      My bestselling and highly recommended Unity book has been fully revised! Unity in Action, Second Edition teaches you to write and deploy games with the Unity game development platform. You'll master the Unity toolset from the ground up, adding the skills you need to go from application coder to game developer.

      Foreword by Jesse Schell, author of The Art of Game Design

      Don't take my word for it being good, look at the sky-high ratings on GoodReads.

      You can order the ebook directly from the publisher's site, or order the book on Amazon to get both the physical book and a coupon to download the ebook!
    • By ThunderTwonk
      Hello everyone, I am working on a game idea and since I am still in the process of learning C# and the features available in unity I was hoping some of you might be able to offer me a little insight on things in general for getting started.
      I guess the basic components of what I'm wanting to create would be a Multi-levels management/city builder/rpg.
      The goal is to provide a framework for players to interact with, build in and affect the world both from a 3rd person action RPG as well as a zoomed out 4x style view (This would be something unlocked through gameplay)
       
      As for my questions go I was wondering if anyone had resources that could help me learn.  I've been on youtube as well as enrolled in an online course for basic unity and C# and will continue those but if anyone has any words of advice, a place that has good information and tutorials etc.
       
      Thanks for your time.
    • By Cahit Karahan

       
      Hi, I'm new in this forum. It is honorable to see such communities exist. I would like to share my new game. I did for android with unity. I know the game is a little awkward , but you have to know that this game is from the time when Unity's name is Unity3D  I have made my first game when I was 12. Now I am 22.  I have taken a lot of experience in this process and I can make better games nowadays. I have published this game nowadays but actually this game is very old but also it is very special for me :))
      I have just wanted to retouch and share this game, because it has a very important place for me.
       
      DESCRIPTION FROM GOOGLE PLAY STORE

      It's a special free 3D horror adventure action game for the halloween. Fun with scary sound effects and musics, 3D realistic graphics, you will feel the horror in the deep of your heart. Use your reflex. Totally free adventure. Totally scary horror game. 

      Tamarra, she is a beast from our world. She needs to consume souls from innocent people to stay alive. Story begins, the old Elaris tribe had lost their everything because of this beast who lived in the well. Araknas was the most powerful warrior of the tribe. One day, Araknas's mother was killed by the servant beasts of Tamarra. That's how Araknas's journey to the well begins. Tamara's well is guarded by horrible beasts. Araknas has to pass all servant beasts until he reaches Tamarra.

      Even death at the end is worth the revenge. 
      Are you brave enough to jump into Tamarra's well?

      Survive from witch attacks, clown attacks and many scary creature.

      - Realistic 3D graphics.
      - Scary sounds.
      - Scary musics.
      - Best experience with headphones.
      - A demon cage where you can imprison all the demons one by one
      - The witches do not like help, but they love blood stone. Witch store where you can develop your abilities and get new abilities.
      - Countless beasts.
      - At the end of the well there is a hidden surprise for you.

      *We do not recommend this game to people with clown phobia, spider phobia, or panic attacks.*

      **!!!**Note : This game is an early-access game, we are upgrading new features every day, new beasts, new improvements, as an example online 1vs1 fall on the list, so stay on connect and follow Halloween : Horror Well on Google Play.**!!!**

    • By INFRA
      SCAN. DRILL. SURVIVE.   ISOLATED Release in May 1st 2018   https://store.steampowered.com/app/805950/Isolated/   A game by Jérémie Bertrand Music & Sound Design by Pierrick Querolle *** Our solar system has been invaded by strangers. For the purpose of a possible negotiation, a team of astronauts is sent to the moon. Alas, they are shot before even arriving on the scene. Only one astronaut survives the crash and his only goal will be to go home...   GAMEPLAY   Shoot enemy ships to avoid being invaded. Be precise in your movements, because it's better to lose a bit of life at the top than to lose it all at the bottom. Take out your drill to destroy the stones in your path. Validate your identity to cross the different laboratories. Reach the flag before losing your three lives.   And all that... at the same time! Will you be able to go home? If the answer is yes, how long will it take?
    • By BigJiggly
      Hello! So, I've been the leader of BJP for a while now. I'm a bit bored of taking the role I always take, leader. I was hoping someone out there is looking to forge a team maybe and needs a programmer. 
      I have experience mainly in the Unity engine(C# intermediate) and I have a very small amount of knowledge on Shaders, as well as experience on developing games(usually end up stuck in dev hell) and leading experience from my last team which at one point reached 11 people. I personally love the Unity engine and prefer to use it as it's the development environment I'm comfortable with. 
      I have used Unity for over a year and a few months, I'd consider myself an intermediate at the Engine, but to this day Unity still surprises me. 
      I live in the United Kingdom, I find it a bit strange to work with other programmers as the ones I've worked with tend to leave their code heavily unoptimised and I'm a on the go optimise kind of guy, I also like to get things done quickly.
       
      If you're a new team and need a programmer that has high levels of ambition and strives to maintain the motivation throughout the team, then I'm your guy. I don't care if you're just beginning because I'm all for helping people learn!
       
      To finish this off: I like to get things done and I like to get them done right the first time, if I fail I will do it again and again, etc, until I loose all motivation. So if you're a modeller or an artist, please don't leave me to do all the modelling/art as well as the programming and sound. I do have experience in all those areas but my main power is in programming and I'd prefer to keep it that way.
       
      [If this was posted in the wrong forum, sorry, I don't really know the layout of this website yet]
  • Advertisement
  • Advertisement
Sign in to follow this  

Unity Scene design.

This topic is 1905 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello everyone,

I currently need to decide what type of scene will my game need.

a/ A root and only one level of children.

b/ Not only the root but all objects can have children

 

What is making my decision harder is that I don't know what the physics engine will do.(I guess bullet physics)

 

If I didn't have physics -> I've got bus and a character. Bus is parent of character -> character's matrix is being multiplied by its parent to find where I should draw it.(and where should the logic process it)

I don't know how physics handle these stuff. I don't know can there be any connections like this(I've been playing with unity3d. I know just the most basic stuff about physic's objects)

 

For the design itself I'm following ( http://software.intel.com/sites/default/files/m/d/4/1/d/8/Designing_a_Parallel_Game_Engine.pdf )

I have an universal scene. I create the bus and character there like I said above. How should I recreate this in the physics system's scene?

Should it be flat? Do I need some connection between a parent and a child(like the transform multiplication like I said above)?

 

Note: I don't need really advanced physics simulations, just rigid body and collision.

 

So...how would you do this? 

Share this post


Link to post
Share on other sites
Advertisement

In my opinion it would be best to have all scene objects capable of being a parent and to hold children. It will just make object handling a little easier. Something like the following maybe?

class SceneNode
{
	std::list<SceneNode*> children;
	
	/*Add methods here for adding and removing scene 
	nodes and any other common node methods too*/
};

class Bus : public SceneNode
{
	/*Bus related methods*/
};

class Character : public SceneNode
{
	/*Character related methods*/
};

 

As for physics, you mentioned Bullet...It holds it's own scene structure and feeds your scene objects with updated transforms. So it basically runs independently to your scene graph and you'd be using Bullets interface to move objects around. To create rigid bodies you feed Bullet with raw geometry (or use simple primitives) and positional data. You'd then tell Bullet what rigid bodies are attached to each other (parent/child relationships).

 
Note: I don't need really advanced physics simulations, just rigid body and collision.

Unfortunately once you start colliding multiple objects together and want correct collision detection and response, it becomes rather tricky, and implementing your own solution basically ends in recreating the wheel so to speak. Bullet will only do what it needs to do in terms of calculations so you wont be loosing out by using it.

Edited by Nyssa

Share this post


Link to post
Share on other sites

Thank you for the answer. Pretty much everything I need. I already have experience coding such things(however without physics) and I usually do the same thing you suggested. 

I'll just make my universal scene which support parent/children, create a function which will iterate through parents to get the real world position of the node. Then I'll create the physics system like a wrapper to bullet physics. Bullet will take care of its own structures.

Share this post


Link to post
Share on other sites
Don't think of it as a monolithic structure. Keep as many copies of the data as you need. Graphics system needs to cull geometry based on visibility? Keep a quadtree/bsp tree/whatever around. Need to quickly look up certain game objects based on string keys? Keep those in a dictionary. Need a data structure specialized for physics? Have one of those around (if you're going to be using a 3rd party physics api then it will keep it's own copies of the data it cares about).

A general purpose scene probably doesn't need to support parent-child relationships. You only really need that for calculating world transforms (and you've got another class for that right?). If this is the "master list of all game objects" type of scene, then really all it needs to be is an array or some sort of dictionary if you have unique ids. Edited by turch

Share this post


Link to post
Share on other sites
my strategy:

the large scale world is divided up into "regions". each region is a fixed sized space (basically like a big cube), and they are laid out in a giant grid. as-is, the regions are 512x512 meters (or 16384 ~1.25 inch "units").

an idea here is that a player may only see into at-most the 4 nearest regions, and anything beyond this can be saved to disk and unloaded (or reloaded again if it comes back into the visible list).

( edit/add: you don't want to aggressively load/unload though, since a player jumping around near the middle of a region would cause considerable loading/unloading, so a list with maybe 16 regions is better, but with only the nearest 4 being "active", and drive loading/unloading via minimum and maximum distances, say, force-load if distance<192 meters, and unload at between 768 and 1536 meters. likewise, if the engine has "chunks", but the unload radius may be smaller. )


within each region (apart from voxels), objects are sorted according to a dynamically build BSP-like structure.
this tree is rebuilt as objects are added/destroyed or move around.
the advantage of a tree like this is that it allows quickly answering questions like "what is the nearest X" or "is there anything in this particular area of space?", without needing to check against every object in the scene.

say, an object is running or falling, do we really want to check against every object in the scene every tick? typically not.
a tree allows quickly identifying and eliminating the vast majority of objects for which there is no chance of colliding with them.

however, this tree is not directly regarded as part of the object (in the same sense as parent/child relationships), but is more sort of a "behind the scenes" type thing, and as an object moves around, the tree might change around under it, or if it crosses a region boundary might actually jump from one BSP to another.

most entities and similar are otherwise treated as more-or-less a flat list. typically, there are not any explicit parent/child relationships, but some relationships may exist informally (for example, projectiles remember who fired them, AIs/NPCs remember who their current enemies are, ...).

during run-time, each entity may also be assigned an "ID number" used to identify it (like, over the network protocol), but this ID number is not persistent.


note though that there is not actually a single unified list of objects for the entire engine, but rather there may be around 4 of them:
the server-side scene-graph, which basically tracks all world objects (and runs all the AI, physics, ...);
the physics-engine graph, which mostly just deals with objects using fancy physics (otherwise, the physics engine is idle);
the client-side scene-graph, which basically contains whatever entities the server is telling the client about (the locally visible collection of entities, which basically holds information like each objects location/velocity/model/frame/effects/...);
the renderer's "modelstate" list, which mostly keeps track of currently-visible scene objects (this may include things like the instance of an entity's skeletal model, its current bone positions, per-frame vertex/normal and triangle-face arrays, ...).

so, for example, if an entity exists on the client, it may be given a modelstate if it is potentially visible, but may not get a full state until it is determined "actually visible" by the renderer (is uses a special visibility-determination pass, employing various checks to try to determine what is/is-not relevant to the current visible scene), and an entity wandering off-camera may well have its modelstate destroyed (the modelstate graph is thus highly volatile, and in some cases the renderer may destroy it at-will, forcing the client-end logic to rebuild it).


the reason for different lists is that they exist in different parts of the engine and deal with different information.
for example, the server-side entities contain lots of fields that have no relevance to the renderer;
and, the renderer contains lots of fields that have no relevance to AIs or physics;
and, for example, the client-side scene-graph knows a model by its model-name, and largely manages communication with the server, whereas the renderer's modelstate knows it via an instance pointer and internal (model-type specific) vtables (and non-visible objects are never given a modelstate);
...

well, and also because my engine is mostly broken up into multiple DLLs, and I prefer not to share structures between different libraries.


or such... Edited by cr88192

Share this post


Link to post
Share on other sites

What is making my decision harder is that I don't know what the physics engine will do.(I guess bullet physics)

I'm not sure what it's causing you trouble here. Physics representation must totally be separate from others.

It is worth noticing that for anything that is not a dynamic object (Bullet slang) the physics does absolutely nothing, in the sense the objects will stay still by themselves.

Kinematic objects do move according to application, not physics.

 

You'd then tell Bullet what rigid bodies are attached to each other (parent/child relationships).

Actually no, they are not parent/child relationships. There's no such thing as a "parent" rigidbody. Connecting rigidbodies by a constraint gives them equal rights.

 

I actually read a lot of possibly premature optimizations in this thread. Last poster even takes a stab at streaming, client-server architectures and such. My personal suggestion is to use iterative design. Add features after you have the need for them. You cannot design a solution for a need you don't understand.

 

Actually, my "scene" is a std::vector of batches. Yes, you read it right. I don't even need to make it hierarchical. Yes, I do have problems with my most complex data sets on the lowest end hardware I'm targeting (which is 1st gen Intel Atom FYI). Realistic datasets run just fine.

Share this post


Link to post
Share on other sites
actually, I was mostly describing how my engine works, as an example...

granted, it does itself use a client/server architecture (both in single and multiplayer), and loads/saves parts of the world dynamically.

actually, in this whole design, the server end is the main authority (pretty much everything on the client-end is streamed over from the server).

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement