Node-based rendering
My first question is what does your graph represent? It sounds like you want it to represent the things which need to be rendered. Does the graph encode the order of the rendering? Or is it just a container that holds all the objects to be rendered? It's not clear from what you've shown here why you want things in a graph. (Which isn't to say it's a bad idea. It's just not clear what your reasons are.)

The code you've written is pretty straightforward and seems mostly reasonable. It's very readable, which is great.

What is the purpose of a Node? You've made it an Entity, but it's not clear to me that it should be. It looks like you want it to be an entity so that it can have a Render() method which calls its components Render() methods. From what you're showing here, it's not clear that a Node ever uses its transforms. (If I'm misunderstanding, then let me know.) If that's the case, I'd make the Node class be a free class that doesn't inherit from Entity. It would look mostly the same. To render, you would either give it a Render() method like it has now, or create a class or function that walks the graph, gets each node's list of children and calls each child's Render() method. I'd probably also rename it to EntityNode since it only ever keeps track of entities.

I notice that Entity's Render() method is pure virtual, but its Update() method is not, though it's empty. Will most subclasses of Entity implement it? If not, then it's fine to leave it as an empty method. But if each subclass will implement its own version, then it should probably also be pure virtual, too.

Speaking of virtual methods, if you're using C++11, you should add override after each virtual method in the subclasses, like this:

class Spatial : public Entity {
    //... constructors, etc.
    virtual void Render (const Shader&amp; shader) override {
        //... method contents ...
    }
    // ... other methods...
};


This can help you catch some hard-to-understand errors as your class hierarchy grows. For example, if you ever change the function prototype for the Render() method, it will remind you to fix each subclass's implementation.

In your main method, you're reading the same object twice, though it's not clear why. That might make sense if you're creating 2 instances of the same object. But if not, it probably indicates a need to structure things differently. Since I don't know your goals there, I can't say which it is.