Two different types of SVG files?

Two different types of SVG files?

Folks, can anyone shed any light on why some SVG files come out great in C3D and other SVG files pretty badly? I've been looking for a 'front end' for Cheetah, and have been using a Autocad like application called QCad (which also works well on Mac OS X), however the SVG file that QCad exports doesn't work very well when imported into Cheetah.

OTOH, My other drawing program, although sadly not a CAD one; Intaglio exports SVG files into C3D really well, and I can say import splines that don't cause C3D to crawl (unlike QCad).

On closer inspection, opening each exported file in Text Edit reveals two rather different looking formats (although they are both supposed to be SVG). I suppose I'm really asking Martin why OS X is happy for one, but not the other, but does anyone else know why?

For the record, here's the Intaglio one (both are plain circles);

<?xml version="1.0" encoding="UTF-8" standalone="no"?><!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"><!--Generated by Intaglio, www.PurgatoryDesign.com--><svg version="1.1" viewBox="143,71,290,290" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"><path fill="#fff" stroke="#000" d="M432,216 C432,295.529,367.529,360,288,360 C208.471,360,144,295.529,144,216 C144,136.471,208.471,72,288,72 C367.529,72,432,136.471,432,216 C432,216,432,216,432,216 Z"></path></svg>

and QCad;

<?xml version="1.0" standalone="yes"?>

<svg width="102mm" height="102mm" viewBox="0 0 102 102" version="1.1"
xmlns="http://www.w3.org/2000/svg">
<ellipse cx="51.000000" cy="51.000000" rx="50.000000" ry="50.000000" style="stroke:rgb(0,0,0);stroke-width:0.250000;stroke-linecap:round;fill:none;"/>
</svg>

The second one looks nice and easy, but Mac OSX actually prefers the first! :shock: :?

I'd love to know what is going on?!

PS, sorry to all those who may find this intimidating- fwiw, it scares the heck out of me too! :lol:
 
Mac OS X prefers it or Cheetah 3D prefers it?

The problem appears to me to be that the first example is a spline (which is what C3D wants) whereas the second is an ellipse.

Most spline-based drawing programs (unlike CAD programs) create "circles" as bezier approximations, so if you export something drawn with their primitives you'll actually get a spline.

My guess is that C3D supports splines but not other primitives. Just a guess.

The equivalent for a 3d format would be supporting meshes vs. primitives ... primitives are "simpler" but also pretty much useless.
 
Mac OS X prefers it or Cheetah 3D prefers it?

The problem appears to me to be that the first example is a spline (which is what C3D wants) whereas the second is an ellipse.

Hmm- good observations! I think maybe Cocoa prefers it (as in the former), because in a way, that is a far better implementation of the use of the code. Maybe that's why people don't (or didn't?) like Mac for programming on as opposed to Windows? If the end result is just to be a circle, then prompting just to draw a circle from a spline, would make more sense- but only from a lazy person's point of view. However, from a Mac point of view, it would make a lot more sense to get it absolutely right in the first place- VERY Mac/ Steve Jobs IMO!!! :lol:

So in other words, it seems like OS X is making more of a fuss over what it decides is a good file, compared to a Windows-based program saying 'what the heck, a circle is a spline'. (It would also explain why PC's always have to be twice as fast as Macs to work!)

No- I think my conclusion is that the problem here, lies with QCad, and even the Trolltech framework that it is written on. Now whether Ribbonsoft will change their code just for Mac users remains to be seen :shock: :roll:
 
Hi,
that is not Mac OS Xs fault. OS X can't load SVG files by default and therefore there is no API to use.

So I wrote my own SVG loader for Cheetah3D but it doesn't support the full SVG spec which is quite long. I only support the important things like splines, transformations, etc.

SVG primitives like ellipses, rects, etc. are not supported and I currently don't plan to support them. Just make the primitives editable in your 2D drawing app before you export them.

Bye,
Martin
 
SVG primitives like ellipses, rects, etc. are not supported and I currently don't plan to support them.

That's a shame, because for a moment then, I thought that we may have had an alternative for the dreaded Autodesk DXF.

However, the humble PDF could be the way to go- especially now.

Just make the primitives editable in your 2D drawing app before you export them.

:? What? Do you mean exploding them beforehand? I don't understand?. Primitives? I thought primitives could be '3D' only? Do you not mean entities??

Tom =0)
 
When you import an SVG (2D file) you get a bezier. There's no perfect translation from a "circle" (or ellipse) to a bezier, so you get an approximation. I don't know how the program you're using works, but if it's a CAD program it probably "disapproves" of translating circles into approximations made of beziers. The solution is to work with beziers or convert stuff (if possible) to beziers.

A 3D analogy would the 3D Studio Max's "coil" primitive. If you had a Max document comprising a "coil" and exported it to Cheetah 3D via some format which stored it as a "coil" vs. as a mesh of triangles, no program that didn't implement "coil" primitives would be able to import it.

Beziers are to SVG as 3D meshes are to 3D -- the most general kind of object.
 
Back
Top