Commit Graph

20 Commits

Author SHA1 Message Date
manuelk
fab0527f91 minor FarPatchTables::PatchMap code refactor :
- replace use of std::multimap with an std::sort
- refactor some methods into PatchParam
2013-06-11 15:59:43 -07:00
manuelk
5fe38c3ac0 If Hbr carries no fvar data, then we shouldn't attempt to build fvar data tables in Far,
where the factory requests it or not...

fixes #169
2013-06-04 17:53:28 -07:00
manuelk
85a3001120 Work in progress on EvalLimit : added Gregory & GregoryBoundary kernels.
Note : GregoryBoundary does not generate the correct surface yet (bug to be squashed soon)
2013-05-24 16:29:28 -07:00
manuelk
1cfcb2ae79 comments 2013-05-17 16:02:03 -07:00
manuelk
3869be18b7 Renaming PtexCoord as PatchParam and general cleanup of the ptex name where it
doesn't belong
2013-05-17 09:47:44 -07:00
manuelk
78d7ce0867 add the ability to FarPatchTablesFactory to select how many levels of subdivision to
create patch tables arrays for when instantiating the FarPatchArrayVector.

default of -1 selects the highest level of subdivision that the factory is able to generate

note : this functionality will eventually have to be exposed to client code from the
FarMeshFactory API
2013-05-16 18:38:06 -07:00
manuelk
ad3bacbbbb remove topology data from FarMesh and refactor uniform / adaptive
code paths using FarPatchTables for all serialized topological data.
2013-05-15 17:53:40 -07:00
Takahito Tejima
d8734690b7 msvc build fixes 2013-05-13 18:43:05 -07:00
Takahito Tejima
a2bbed2a8b Merge branch 'dev' of https://github.com/manuelk/OpenSubdiv into dev
Conflicts:
	opensubdiv/far/patchTables.h
	opensubdiv/far/patchTablesFactory.h
2013-05-09 09:34:58 -07:00
Takahito Tejima
f592e90067 fix OsdGLDrawContext to follow far patchtables refactoring. 2013-05-09 09:23:01 -07:00
manuelk
20641e3b2c code cleanup / comments 2013-05-08 18:47:36 -07:00
manuelk
4230e12d95 first pass at refactoring FarPatchTables 2013-05-08 17:06:59 -07:00
manuelk
4c0c6161d4 Feature adaptive refinement causes Hbr::GuaranteeNeighbors() to leave behind
some un-connected face-vertices. FarSubdivisionTablesFactory has been hardened
so as to not trip over these, but apparently Gregory patch valence tables
generation is tripping over one of those in FarPatchTablesFactory.

fixes #162
2013-05-07 12:32:05 -07:00
manuelk
7554321413 Minor code clean-up of FarPatchTablesFactory :
- removed redundant counter / pointer struct
- renamed some of the variables to be less confusing
2013-05-06 15:00:39 -07:00
manuelk
12eea1cf0b Checking all accesses to 0th. element of std::vectors in FarPatchTablesFactory for empty vectors.
This should fix the exceptions thrown by Windows checking STL vector boundaries.

fixes #155
2013-05-01 19:36:28 -07:00
manuelk
e6e7c96a52 We need to leverage our per-patch ptex indexing scheme in the EvalLimit API.
- replace ptex indexing with the FarPtexCoord structure as a way to pass per-patch
  ptex data to the shaders.

  We are replacing a vector<int> arranged as :
  int[0] : ptex face index
  int[1] : (u,v) as 16 bits encoding the log2 coordinate of the top left corner

  Instead we are now using a struct arranged as :
  int[0] : ptex face index
  int[1] : is a bit-field containing u,v, rotation, depth and non-quad

  The u,v coordinates have been reduced to 10 bits instead of 16, which still
  gives us a lot of margin.

- Replace OsdVertexBufferDescriptor with something more adequate for general
  primvar representation (this name will probably eventually change...)

- Improve OsdPatchDescriptor
    - add a "loop" boolean (true if the patch is of loop type)
    - add a GetPatchSize() accessor

- OsdPatchArray :
    - remove some redundant elements (still more to do there)

- Fix all shader / examples / regressions & stuff to make this all work.

fixes #143
2013-03-22 18:20:50 -07:00
Takahito Tejima
8efecb0fca Batching stuffs: generalized kernel batches, table/dispatcher refactoring, multiMeshFactory, drawContext, etc.
2 client APIs are changed.
- VertexBuffer::UpdateData() takes start vertex offset
- ComputeController::Refine() takes FarKernelBatchVector

Also, ComputeContext no longer holds farmesh.
Client can free farmesh after OsdComputeContext is created.
(but still need FarKernelBatchVector to apply subdivision kernels)
2013-03-07 17:50:15 -08:00
manuelk
25f79e7ff2 - change adaptive refinement in FarMeshFactory to not refine inside holes,
while retaining a necessary 1-ring on the inside of a hole edge

- add IsInsideHole() function to HbrHalfEdge

- add HasChild() function to HbrVertex and HbrHalfedge

- add a regression shape with adjacent holes and creases (tests dart, crease & boundaries)

Note : this does not address hierarchical edits inside holes or hole tags in hierarchical edits

fixes #78
2013-02-20 14:12:09 -08:00
manuelk
a52c70ab8b First pass implementation of holes :
- make sure HBR passes down the hole tag to children when subdividing faces
- minor API modification : allow to unset the hole flag on a face
- modify uniform / adaptive FarMeshFactory to be aware of the flag
- make the FarSubdivisionTableFactory assert when finding unconnected HBR vertices (as it should)

* Uniform subdivision :
    The refinement scheme only creates faces & vertices necessary
    to maintain the one-ring around the edges of a hole, so this solution
    is quite efficient.

* Adaptive subdivision :
    At the moment we are still performing full topological analysis on holes and
    only skipping patches associated to holes. This is sub-optimal in 2 ways :
        1. the topological analysis can potentially be cranking on a lot of unnecessary
           geometry
        2. even though we may not be drawing the patches, the compute stage is still
           applying kernels on all the control vertices of these patches.
    We will have to revisit feature adaptive subdivision & holes, so keep the issue active.

fixes #78
2013-02-13 14:34:33 -08:00
manuelk
10c687ecd5 Release Candidate 1.0 :
- [Feature Adaptive GPU Rendering of Catmull-Clark Surfaces](http://research.microsoft.com/en-us/um/people/cloop/tog2012.pdf).

- New API architecture : we are planning to lock on to this new framework as the basis for backward compatibility, which we will enforce from Release 1.0 onward. Subsequent releases of OpenSubdiv should not break client code.

- DirectX 11 support

- and much more...
2012-12-10 17:15:13 -08:00