v1.5 updates

29 views
Skip to first unread message

Magnus Wrenninge

unread,
May 6, 2014, 1:38:15 PM5/6/14
to field...@googlegroups.com
Hi Everyone,

A small update on v1.5 development:

After a rather long lull in development, we're currently pushing on MIP fields in the dev_v1.5 branch. The data structures (MIPDenseField and MIPSparseField), their respective I/O routines, as well as filtered interpolation are all in place, so we are getting close to a working set of tools. It turns out the current makeMip() function has some filtering issues, so we'll be addressing those in the next couple of weeks.

If anyone is interested in adding support for MIP fields to their code, please take a look and see if the current API satisfies your needs.

Right now, the usage will be something along these lines:

// Construct a MIP field from plain data
MIPSparseField<float>::Ptr mipField = makeMip(somePlainSparseField);

// Perform interpolation given a sample point and the spot size
MIPLinearInterp interp(*mipField);
float filteredValue = interp.sample(vsP, wsSpotSize);


Magnus

Rob Pieke

unread,
May 6, 2014, 5:08:40 PM5/6/14
to field...@googlegroups.com
> float filteredValue = interp.sample(vsP, wsSpotSize);

Just to clarify, are the spaces for the position and size meant to be different, or is the above a mini-typo?

Very excited to (finally) see this support coming in :)

Magnus Wrenninge

unread,
May 7, 2014, 2:35:54 PM5/7/14
to field...@googlegroups.com
Yes, they are in different spaces. The reason is that the interpolators traditionally don't want to care about Mappings. So they always take the lookup position as a voxel space coordinate. 

The reason the spot size is in world space is that it's just as easy to find the MIP level using world space as voxel space. If we wanted to use voxel space it would mean one more property that must be transformed, preferably by transforming each of the three sampling differentials dPdu/v/w (which is in world/object space)... So, it's an efficiency issue, basically. 

Magnus





--
You received this message because you are subscribed to the Google Groups "Field3D dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to field3d-dev...@googlegroups.com.
To post to this group, send email to field...@googlegroups.com.
Visit this group at http://groups.google.com/group/field3d-dev.
For more options, visit https://groups.google.com/d/optout.

Magnus Wrenninge

unread,
May 19, 2014, 8:25:35 PM5/19/14
to field...@googlegroups.com
I just committed a complete MIPField to the dev_v1.5 branch. It includes new resampling code that 'does the right thing'. It's currently single-threaded, but will be multi-threaded in the next week or two.

At the same time, I consolidated all of the previously duplicated code from MIPDenseField<T> and MIPSparseField<T> into MIPField<Field_T>. For simplicity's sake, MIPDenseField<T> and MIPSparseField<T> still exist as classes, inheriting from MIPField, but adding no members.

Thus, you still instantiate a MIP field using these two subclasses, which makes the syntax nicer.

  MIPSparseField<float>::Ptr mip = makeMIP<MIPSparseField<float> >(someSparseField);


Reply all
Reply to author
Forward
0 new messages