I am trying to overlay some 2d interpolated curves (ON_NurbsCurve) I created with RhinoInterpCurve on top of my viewport the same way Draw2dLine, Draw2dRectangle work. Am I right saying that one way forward is to subdivide my curves to small segments and send those starts and ends to Draw2dLine?
I also looked at the SDK example cmdSampleViewportDecoration (dislays text using an event watcher) and I was wondering if it would make sense to follow a similar approach for my curves using DrawNurbsCurve?
I created a real time renderer plugin based on the SampleRealTimeRenderer SDK example to add some projections I need for daylight studies such as Waldram projections. Moreover, I created the actual Waldram diagram which is a set of interpolated curves and I want to overlay those curves on top of my viewport in order to be able to “read” the image of my viewport. I need those curves to be overlayed in such a way that pan, zoom and rotate actions have no effect to those curves.
I’ll see what I can come up with. Assuming I’m understanding the goal here, it seems like all that needs to be done is draw this “set of interpolated curves” inside a conduit’s overlay channel.
I’ll put something together that just draws a few simple curve primitives on the glass, and see if that’s enough to get started.
That’s exactly what I am trying to achieve. Btw, not sure if relevant, some of the curves I am drawing modify the attributes of the ON_NurbsCurve in terms of the m_linetype_index to achieve a dotted pattern.
Are you drawing these curves now?
Are these curves in 3D space, and you want them projected onto the screen in 2D space?
How are these curves managed and maintained?
Simple screen rectangles are one thing, but if you have a bunch of 3D curve objects, that are also using line types and patterns, then things get a bit more complicated, so I want to understand what you have internally, and what/how you want things to end up looking when everything is said and done.
I attach a zip that contains three wip files (the command and the necessary functions in a .h and .cpp). Using those and running the command RRTWALDRAMUH in a rhino file (units in millimeters), a 2d (XY axis) Waldram diagram will be created in 3d space composed of continuous and dotted lines. I also attached a screeshot that shows a waldram render coming out from a realtime renderer and a manual overlap of the diagram. Did I clarify things a bit better? Let me know if you need any additional info.
Sorry for the delay… had other pressing matters yesterday.
Attached is a plugin project that demonstrates how I’ve done this. I may have gotten a little carried away by adding colors and thicknesses to the mix (which currently is off by default)…but commenting out one line of code can/will produce something that uses those attributes.
That opened a small can of worms that normally wouldn’t have revealed itself if everything was using the same attributes.
Anyways, the plugin should be pretty straightforward, and I’ve provided some comments in the code.
I’ve created files called “CurveUtilities.cpp” and “CurveUtilities.h”, which contain all of your functions… However, I had to slightly modify some of the routines so that 2D (X, Y) screen coordinates are used instead of world coordinates. This allows me to simply create a single screen-to-world transform for any given viewport and use it as the model transform for drawing all the curves, thereby projecting them onto the given camera’s frustum.
I also had to include an event watcher that cleans up these curves and disables the conduit when a file is closed/opened, or a new one is created… it’s pretty trivial, but needed to be done nonetheless.
The ZIP file contains both the source and a release version of the plugin (.rhp)… The command it defines is “RhinoCurveHUDEx”, which is used to toggle the curves on and off for any given viewport.
I’m sure there are issues and probably some confusing parts, so please feel free to ask as many questions as needed.
There’s no magic going here… I just store the current dimensions used when generating the curves, and if those dimensions are different at the time I go to draw the curves, I nuke the current curve-set and regenerate them again based on the current dimensions.
That being said, conduits do have an override called “NotifyConduit()” that gets called in very specific cases, the two you’re probably interested in are “CN_FRAMESIZECHANGED” and “CN_PROJECTIONCHANGED”… So in your conduit, if you listen for those notifiers, you’ll know exactly when Rhino knows if/when the frame size or projection has changed, and you can act accordingly. I didn’t use this mechanism since it was just easier to cache the frame size and do my own comparison.
Hope that helps.
Note: I posted the source to the plugin, so you can see what I’m doing … look for “m_frameSize” and all references and usages of it…should be self-explanatory.
I am still going through your example to try understand how you are drawing the curves on the screen and surely it will take me quite some time to get there.
On the same time, I start looking on how to draw an ON_Hatch produced from RhinoCreateHatches() as later on I will need to draw some text on top of it.
Noticing that the curves are drawn using the Draw(dp) on a const CRhinoCurveObject* , I thought to use const CRhinoHatch* for the hatches but then the Draw(dp) method does not seem to draw anything… I did manage to use the DrawHatch() using an ON_Hatch but I am not sure this is useful for screen overlaying.
