3D Plot Axis Labels

3D Plot Axis Labels

Despite my best efforts fiddling with the Array Viewer, I cannot get the axes of a 3D plot to display any text (e.g. the scale for that axis).

I see from pictures in the gallery that it is possible, but just can't seem to figure out what settings to change to get it working.

Any tips appreciated!



7 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.


To be truthful, I'm also using the OCX and the object model, but I've been using the 'To Viewer' functionality as a debugging aid and a see-how-to-do-it tool. Once I figure out the correct settings in the viewer, I can code them through the object model.

I was frustrated to find that there aren't any 'auto size' or 'auto fit' functions (something along the lines of setting the size parameters and then have a function to automatically set the transform parameters to ensure that everything is displayed within your 'size' cuboid).

There is a VB sample with the download that has XYZ axes on it (...Program FilesIntelArray VisualizerSamplesVB6XYZPlot), but it doesn't disply any text on the axes and the setup seems ridiculously complicated. Again, why there aren't any 'auto-axis' functions I can't imagine....



I'm in the same boat, but I can't even get the axes in my 3D plot to
render! I'm using the AvGraph .OCX and the Object Model.

Our symptoms have something to do with IAV's tendency to punt whenever
a drawable object's parameters aren't completely and correctly
specified. In my case, at least, the failure of my axis to be
rendered seems to have something to do with not setting up the axis'
transform properly, so that IAV can't fit everything (labels, tick
marks, etc.) into the space provided for the axis. It gets
confusing trying to track which AvTransform and or AvPosition parameter
seems to be doing something to the axis...

It would certainly help if there was a single example anywhere showing how to set up an axis for a 3D plot.

Elias Sabbagh


Thanks for the pointer, and I'll check out that particular example.

I think that most of the object model complexity is hidden from the
majority of IAV's users, which are F90 programmers accessing it through
the convenience functions Create3DGraph() etc. Since I'm using
Delphi, I figured it would be easier to use the object model directly,
rather than link to the C routines from Delphi (and deploy the .dll
containing them). Now that I'm hip-deep in it, though, I wonder
if I'm really saving myself work!

It would be nice to have native Delphi and other implementations of the
F90 and C routines that do the grunt work of setting up graphs using
the object model. Maybe I should add that to my wish list (or
todo list!). If Intel releases IAV to the open-source community,
maybe someone could write that wrapper layer to save folks some time...

Elias Sabbagh

Yes, it does seem that getting the setting 'just right' is the key - roll on Open Source is all I can say!

Unfortunately, I've had to temporarily move off from looking at this, but I'd be very grateful if you'd share any breakthroughs you have (assuming you have any!)




OK, I've had a "breakthrough" with my "non-rendering" axes.

I was stupidly setting the alpha channel to 0 -- "full transparency" --
in the axis.Color.Front property! In Delphi, hexidecimal
constants are represented syntactically with a '$' symbol out in
front. I was setting

xaxis.Color.Front := $00000000

and getting a completely "whited out" axis, which kind of looked like
screen flicker when the camera was rotated around the graph. I
fixed things when I set

xaxis.Color.Front := $ff000000

Now, the Delphi compiler will issue a warning that this $ff000000 value
is out-of-range for the Color.Front parameter, which is represented as
an integer after Delphi imports the type library into its
component library, but fear not -- everything works.

You can avoid the warning by setting

xaxis.Color.Front := $000000 // leave off the high-order byte

and also setting

xaxis.Color.Transparency := 0.0

OK, I'm a careless idiot, point taken -- but the default behavior for colors shouldn't be to make them transparent!
My faulty assumption of opacity shouldn't have been punished.
When my axes looked like screen flicker, I had naturally assumed that
my problem lay with some combination of the other hundred or so
parameters in this very flexible toolkit, and it wasn't until I'd
exhausted most of them that I managed to check my assumptions about
transparency. At least I know that the axis wasn't getting
"clipped" by an improper AvTransform parameter setting or something.

Now, the next step is to place the axes and labels where they should be!

I suppose that this is how expertise is created. Slowly, painfully, and embarassingly.

Elias Sabbagh

which is teh next step?.

Leave a Comment

Please sign in to add a comment. Not a member? Join today