Jump to content
Ultra Engine Community

Admin

Administrators
 View Profile  See their activity

  • Posts

    3,209

  • Joined

  • Last visited

 Content Type 

Posts posted by Admin

    AddRef()/Release()

    in Programming

    Posted

    My understanding of this is that when we are passing pointers of LE objects to other LE objects we have to make sure all those objects that were passed the pointer know if the pointer is still valid or not before it uses it. So I assume inside these LE objects it calls RefCount() before using any external LE object to make sure it's > 0.

    You usually will not need to ever worry about calling AddRef(). It would be an unusual case.

     

    1) Why not just have the LE functions call AddRef() for the functions that accept pointers to other LE objects on the passed in object so we don't have to remember to do this manually? Is it because we want to give them a chance to use objects in multiple places? How often is this really done? Is it really hard to use objects for only 1 thing? It's much more common, and required in some cases, that we need to pass LE objects to other LE objects.

    That's exactly how it's done. Commands that accept a pointer to an object for storage will increment that object's ref count, and decrement it when finished with them:

    http://www.leadwerks.com/werkspace/page/documentation/_/command-reference/material/materialsettexture-r184

     

    2) I think we aren't supposed to call delete on any LE pointers but just Release() which would reduce the count and if it's the last usage the count would be 0. When does LE actually delete the underlying LE resource then?

    When Release() is called, if the refcount reaches 0 the object is deleted.

     

    3) I assume calling ::Create() sets the internal ref count to 1 (or the ctor of the Entity class)?
    All objects have a ref count of 1 when created.

     

    4) Why not have LE objects look at the RefCount() inside the destructor and decide if it should actually delete the resources or not if the RefCount() = 0? This way we can still use the normal C++ 'delete object' instead of release.

    If you delete the object, it is no longer a valid pointer. This can cause other objects that use that one to cause a crash when they try to access the object, since it no longer exists. The System::GCDepth thing is a way to prevent crashes if an entity is deleted inside a physics callback.

     

    This is the source for Object::Release():

    	unsigned long Object::Release()
{
       unsigned long result = 0;
	if (refcount>0) result = refcount-1;
       if (refcount==0) Debug::Error("Object reference count error.");
       refcount--;
       if (refcount==0)
	{
		if (System::GCDepth==0)
		{
			delete this;
		}
		else
		{
			Garbage.push_back(this);
		}
	}
       return result;
}

    light penetration

    in General Discussion

    Posted

    If those brushes are using a dynamic lighting shader, the light would not cast shadows in 3.0. You can use a lightmapped material, calculate lighting, and it will cast shadows.

     

    3.1 will use a deferred renderer, so the behavior is more natural like you would expect:

    Geometry and tessellation stages

    in General Discussion

    Posted

    Yes, 3.1 has two additional tabs for the control and evaluation shaders. I have read conflicting things over whether geometry shaders are uniformly supported, and haven't messed around with them yet.

     

    The savings on terrain rendering would be that instead of 5 different LOD versions being processed, the tessellator can take care of the LOD, so the patches don't have to be sorted into separate batches by LOD.

     

    I have found it's best to use a tessellation multiplier value and then use the entity distance from the camera to adjust tessellation. This works better than doing a per-primitive approach.

Copyright © 2024 Ultra Software.
All rights reserved.
×
×
  • Create New...