---------- Forwarded message ----------
From: MarioPC <mr.rash....@gmail.com>
Date: 2017-08-10 20:33 GMT+02:00
Subject: RE: [brlcad-devel] Example of heterogeneous density +
masscalculation
To: Mario Meissner <mr.rash....@gmail.com>
Okay,
So since stuff doesn’t seem to work very well on viewweight yet, and since
we need to heavily modify existing code anyways, I decided to move back to
rtexample.
If we want to use Voronoi tesselation as our base model and expand it with
transition vectors, many we have to rethink how we query data as well. It
makes no sense anymore to just query the density at a specific point since
we cannot just interpolate. Somewhere in between the two points, a sudden
change of density might occur. Interpolation would asume some kind of
transition, which there might not be (the value we obtain by interpolation
might be way off the real value). So, instead of asking for the density at
a specific point, lets give our function the whole segment so that it can
correctly return the average density, or even the mass. This way the
function knows where the segment starts and ends, can compute the
projections and apply Voronoi tesselation to determine the different
densities. Then with that info we compute the average density and return it.
With rtexample I won’t have the problem of sharing a pointer to my
point/vector list since I have a main function where I can do all that. My
readDensityPoints() function will also work as expected here.
I’ll start working on this, maybe with just 0 and 1 points for now, and
hopefully make my first ‘complete’ piece of code.
Mario.
*De: *Mario Meissner <mr.rash....@gmail.com>
*Enviado: *miércoles, 9 de agosto de 2017 23:04
*Para: *BRL-CAD Developer Mailing List <brlcad-devel@lists.sourceforge.net>
*Asunto: *Re: [brlcad-devel] Example of heterogeneous density +
masscalculation
Hi Sean!
Thank you a lot for the details. The visualization of Voronoi points was
really helpful. I think I understand your vision and will work on
implementing the first steps as soon as the stuff I mention below is done.
I'm running into some trouble with my code. I need to call
readDensityValues() (user input through stdin) but I don't know exactly
where I should place the call.
Placing it into view_init, view_2init, application_init or view_setup
breaks it: buffer doesn't behave correctly. My exit command isn't
recognized anymore, and when I Crtl-C, it runs the while loop two more
times (printing usage) before shutting off. It feels like there are many
threads running at once and interfering with each other. Might this be the
case?
I'm afraid I cannot deliver functioning code today, but if we solve this
problem I will be able to do so tomorrow. For now here goes the not-working
state.
Next steps:
-> store the points into a file (instead of sharing a memory pointer)
-> make the point input procedure a separate program, or ask the user at
the start of rtweight execution if he wants to create/override the point
list.
Maybe this can solve the problem mentioned in the above paragraphs. How
do you think we should do it?
I also want to mention that the during the next three weeks I will have a
little bit more restricted available time (as I mentioned in my
application). I will steadily advance, but it might feel a little bit
slower than up to now.
PD. What you mean with 'patch' is the result of running svn diff into a
file? If so, here it goes!
Mario.
2017-08-09 7:58 GMT+02:00 Christopher Sean Morrison <brl...@mac.com>:
Fair enough. My next goal will be to make our initial minimal feature
working. In this case this means having a way to let the user define points
that will be used for query_density(), instead of hardcoding them. I guess
for now I will use the .density file as I have no idea how the whole
"material objects" thing should work, yet.
If you have a specific idea/plan in mind, I’d love to hear it. However, I
can’t really envision a good way to extend the tabular .density file format
with the information you need without introducing a problem.
Two options that come to mind would be to modify rtweight to take a
secondary input file (temporary) or implement a material object stub that
has what you need (more complicated, but in the right direction) [1]. For
time, I think the second option is the way to go given the time remaining
and that’ll keep you directly working with the rtweight sources.
[1] http://brlcad.org/wiki/Material_and_Shader_Objects
I guess it's up to you to decide what I should focus on. I could work on
the basics of this new approach so that future work on it can then build on
it and eventually finish it, but that would mean quite a change to what our
initial goal for the socis period was. I'm totally fine with either way.
If we knowingly plan to extend the current materialID system to later point
to an object, then you’ll just have to make sure whatever you read in from
file fits that mental model. Directly modifying rtweight to take a second
specification file will more easily allow for testing N-point cases, so
we’ll just have to be careful it can easily translate into an object.
I think this [checking if there are overlapping points] can also be handled
by changing the way vectors are being defined (or perhaps what they mean).
Instead of having a concept of origins and detachment of point densities,
let density_vector actually refer to a density_point and let the other
struct fields encode the nature of the contribution (effectively combining
your struct combination data into one concept).
I'm afraid I'm not following you here. Could you detail this out a bit
more? The referenced density_point would be the origin of the vector? (if
not, what is it?).
No, at least not necessarily. Density points would be simply a density
specification at a specific point in space. How that value is interpreted
or used nearby would be a separate concept (and handled in code in a
separate struct). In fact, it becomes possible to define reasonable
behavior without any vector information.
Consider two side by side boxes (with a gap between them) that are in the
same region. Under the current system, there’s a materialID=3 which maps
to a density of 7.75 g/cm^3. If I specified a density point somewhere in
one of the boxes as being 8.05 g/cm^3, I would intuitively expect that to
be the density of that box (and only that box). No falloff, no smooth
transition to 7.75, no override of the universe to 8.05.
How to achieve that in code is going to be really tricky for concave
shapes, but I think it’s the simplest and most natural behavior a user
would expect. (keep the simple easy)
The 'nature' of the contribution would be something like rate: linear,
quadratic, etc.?
It’s only once we add a second point or define a transition vector (which
implicitly entails two points) that we have to care about this, but
essentially yes.
And how does this change help us check if there are overlapping points?
So again consider defining points but not defining vectors. If we have one
box and define two density points in the box, that is the density at those
points. Defining the same point as having two separate densities would be
a definition error. Separate them by any meaningful distance and we’ve
effectively defined a density “binds" that maps well to a Voronoi
tessellation of space, like this:
http://alexbeutel.com/webgl/voronoi.html
With that conceptualization, adding in vectors from one point to another
merely changes the space definition to being a continuous smooth transition
between pairs of points. Make sense? That becomes a fully generalize
solution that should capture nearly any material definition while keeping
the simple easy, and complex possible.
>From the rest of the answers in your emails I think I got the idea that you
want to let the user specify both points and vectors as if they were two
means of describing density. Then a vector should be something like a
superset of the point, where we can specify some more information about it
to
describe the continuous transition between the two points the vector spans.
I think you got it. More specifically, vectors augment/extend the limited
info of a density point, describing how it transitions out from a point.
Don't we need to reference two density_points then?
Either as two points (origin pt1 to destination pt2 with an implicit dir)
or as one point and a direction vector, not unitized (so adding pt1+dir
gives pt2). Either should work fine.
Doesn't this method depend too much on the direction from which the rays
come? For example, ptA could be really far from 'IN' if you shoot from
above but really close to it if you shoot from the side. If ptA was the
heaviest point, then shooting from above will turn a huge part of the
material into really heavy, and shooting from the side should weight much
less. I'm not sure if I'm talking nonsense here, I'll check with an actual
example to see it working, but this was my first thought when I saw it.
Hopefully the Voronoi webgl demo helps clear that up. There was only
weighting when we were assuming linear interpolation or vectors to/from all
points. Using the Voronoi / halfspace approach is direction invariant.
For now I'll make my code fully 'complete', as you mention. Then I will get
rid of my 'origins' and make projections onto the shotline (but this will
require some more discussions as I'm not 100% sure how this would all work
and fit together, especially points with no vectors [the question above]).
At some point in the future we will need to take the distance to the
shotline into consideration to make a 'fair' average of contributions, as
you suggested.
It’s also okay if you need to move back to rtexample to prove the concept
first. It’s when the feature is introduced into a production facility that
it should be done “complete”, one bit at a time.
For what it’s worth, projecting onto the shotline is probably only going to
work on convex geometry. For concave shapes, it’s a bit more complex to
know where a given density point applies. It’s certainly resolvable with
the neighboring ray information (because they represent a
quasi-voxelization of space).
Cheers!
Sean
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
