Full Version: Hidden line removal progress

Show messages:  1-14  …  215-234  235-254  255-274  275-294  295-296

Hi Michael,

>Does this happen only if you are generating a shaded background image?

It's inconsistent. If turned off, solids will sometimes stop throwing the error but the result is still flipped vertically.
Turn it back on and it continues to NOT throw the error. Orbit the camera, still okay. Orbit the camera some
more and eventually it starts throwing the error again. It's weird, it's almost like the buffer data gets corrupted
at least in regard to Photoshop. And once that happens it keeps throwing the error and doesn't care whether
the background image is on or off.

The previously attached .3dm is curves only and should always paste, albeit flipped, but sometimes curves only
will also throw the error if selected curves match the edges of unselected surfaces.

-Jeff

---

Hi michael

Yes it seems to be mavericks, if i leave on one screen it is more stable. I read that cranking up the canvas mega pixel value gives more detail, and in doing so it does give me a better pic, at 30 it works but at 35 it crashes every time. I have attached two pdfs a MOI version and an Isodraw version to compare. I know its unfair to compare you to such a mature product, what you've done so far is brilliant.
It seems some of the "weak" areas highlighted in pink need more resolution from the pixel grid to work but as i say it won't go above 30 without crashing. . . FYI the size of this part is approx 60cm square if that helps.

Matt

Attachments:
inertSep-isodraw.pdf
inertSep-MOI.pdf

---

> Damn! That Floyd Rose is so appealing to my eyes I wanna eat it! Nice job. :)

With this new ability, MoI has just increased its street-value many-fold! (er, ya know what I mean)

Martin, those are beautiful, and the new output is amazing!

---

Thanks wastzzz and Mike.

I wasn't that happy with the export results yesterday. Luckily it was me. Now that I run "Construct > Curve > Isect" before each and every export its like night and day.
Excellent work Michael, MoI has become so much more useful.

---

Hi Jeff, re: Photoshop copy/paste problems, can you please contact me through e-mail at moi@moi3d.com and I'll set up a test version for you which reverts some of the changes to the header part of the AI file generation. It seems like Photoshop probably has some bugs in its handling of the old AI v8 file format, but if it worked ok previously it should probably be possible to get it to work again if I just avoid writing whatever particular thing triggers the bug from happening.

- Michael

---

Hi Matt,

> It seems some of the "weak" areas highlighted in pink need more resolution from the pixel grid to
> work but as i say it won't go above 30 without crashing. . . FYI the size of this part is approx 60cm square if that helps.

Right now the hidden line export will crash if it runs out of memory in the middle of the calculation. For the next release I'll try to tune this up to try and make it behave better like maybe just giving up on the export rather than crashing. But anyway that's almost certainly what's happening to you with the canvas size above 30 megapixels combined with a highly detailed model.

If you haven't tried this already, go to Options > View > "Meshing parameters", and set the "Mesh angle" parameter to 30 degrees, and uncheck the "Add detail to inflections" parameter right next to it (do this with MoI empty just after startup). That will make for a rougher looking viewport display but it will reduce memory consumption by quite a bit on heavy models like you've got there.

That might allow you to go up higher with the canvas size setting, which can have a max value of 75.

The overall approach of how the hidden line engine works just might not work very well with that kind of object structure where you've got such little tiny sized edges in comparison to the whole overall object size. If you can possibly cut the model up into some smaller sized pieces and only process one of those pieces at a time rather than a big sized chunk like that, that would probably help quite a bit.

Two of the areas where you've circled where there are little things shooting out - those are probably not actually related to canvas pixel size but are more likely to be surface trim problems where there was some problem getting a proper structured trim boundary during the STEP file import. Those particular surfaces will probably have to be repaired by separating them out, untrimming and retrimming them in order to get them fixed up. If you're able to send me a file with just those problem surfaces and the ones immediately surrounding them I can try to show you how to do that. There is an object repair tutorial here that covers some of the techniques involved: http://moi3d.com/forum/index.php?webtag=MOI&msg=446.17 It's also possible that it could be a mesh generation bug rather than an incorrect trim boundary import bug, it's difficult for me to know for sure without examining the actual geometry.

At any rate, the MoI export you show there even with its flaws at least gives you something that you can work with. I'll see about doing some tuneups to try and improve it further.

- Michael

---

Hi Michael,
This new feature indeed has great promise!

I was able to export my very complex model by turning off inflections and bringing the mesh angle up to 30.
I also had to delete every non-essential and hidden object as the process seemed to include them in the calculation.
Yes, that is how it works, but I think those objects were gumming up the works even though they were "hidden."
Does the PDF export omit hidden objects from the equation?

Also, I would like to suggest and addition to this feature: Could there be a way to use a blank white or solid-color vector object in place of the bitmap?
Or could there be a way to tell the 'background' bitmap to be white without disappearing and showing the outlines beneath?
The bitmap can be whitened out in Illustrator or Corel, but Photoshop hasn't a way to see these layers when importing PDF's.

Case in point: I'm often interested in making the plain, diagram-style vector pics using no fill color, but still blocking out the larger outside outlines.
I could program in a Lighting Option to make everything white... hmm, easier in AI or Corel.

Here is a cool result:



I brought the PDF into Corel where I made the bitmap white. Then I converted everything in a line-art bitmap where I used Corel's auto-trace feature on it.
That gave me a hand-inked look! Added the type next and brought all that to PhotoShop where I gave it all a realistic look.

Again, I am very pleased with the prospect!

---

Very cool result Mike!

---

Dang Mike - that's great!

Hey - speaking of bitmap tracing in Corel Draw.... I use that function almost daily in my work on B&W bitmaps and have never been satisfied even after trying all the settings and tweaking values.

Today, after all the talk of AI on the forum, I traced a B&W bitmap using AI. It came out almost perfect!

Have you compared bitmap trace between Corel Draw and AI?

Ed

---

Thanks Ed,

Corel made some improvements to the tracing feature after X4, as X3's tracing was just horrible. I'm using X6.
As tracing line-art is a staple of my daily work I religiously use Corel 12's stand-alone TRACE program. It lends itself to hand-drawn art and will take bitmaps of virtually any size.
But for some stinking reason they dropped it at X3. I keep a version 12 CD in store, but I worry that I'll lose it someday.
I prefer AI's trace next to that one, which is a vestigial of Streamline, but since I use Corel as my primary and AI as secondary, I rarely touch AI's tracer.
X6's is not that great on drawing but actually does well with basic logos and simple fonts inside of logos.

There are very few setting offered, but they do allow you now to get stacked objects like the old TRACE as an alternative to the odd cut-out ones.

I've been wishing for an output feature like this for a while, but since this came under my radar, I'm just now grasping the possibilities.

I would like there to be some way to get a filled vector shape instead of the bitmap, but I know that for one, the bitmap is rendered from surface polys - and two; the outer outline silhouettes consist of many broken and oddly overlapped segments. A white bitmap would work fine, but all said, this request can be satisfied with a bit of quick levels and trace work in Corel. I ain't complainin' ;-)

---

Hi Mike, woah that is awesome, your pic confused me for a second about why you were showing that photo! :)


> Could there be a way to use a blank white or solid-color vector object in place of the bitmap?

This is fairly difficult because getting a vector object fill means actually joining together numerous different generated pieces and trying to screen out little fragments of things. I don't really have much hope of getting that done anytime too soon.



> Or could there be a way to tell the 'background' bitmap to be white without disappearing
> and showing the outlines beneath?

This one is possible currently by adjusting some lighting settings, just add another one to your lighting presets. The parameters you would set are shown here:
http://moi3d.com/forum/index.php?webtag=MOI&msg=3135.3

Basically if the light intensity is turned up very high it will have full brightness everywhere essentially disabling shading.

- Michael

---

Mike.

That is SO convincing, it's just NOT TRUE!!!!

Looks like you've been carrying it around in your wallet for the last forty years.

Absolutely brilliant :-()



Martin.

---

A little icon work & transparency.

Image Attachments:
Icon_2.png 

---

I noticed few difference in accuracy between MoI's hidden line removal and Rhino's Make2D command.
I am attaching an example of the same 3D model.
MoI output is not bad, but Rhino's one is more accurate (lines are touching and it allows me to use hatching later).
Canvas size was 70. Anyways I'm pretty fine with the MoI output, but could you explain me how the hidden line removal algorithms of MoI and Rhino are different? Are they using a different approach?
Is it possible in the future to improve the hidden line feature to get better results at corners/touching lines?
It's just my own curiosity.

MoI:


Rhino:


Thank you.
M.

Image Attachments:
moi.jpg  rhino.jpg 

---

Hello Mike K4ICY, beau bee, bee, buzz, balèze (hulk, huge) in the MoI galery.

---

Hi Max, I think that Rhino's one is based on intersecting curves with one another, while MoI's one is based on following a curve and using a pixel depth buffer to determine whether things are hidden or not.

So yeah they use a different approach and that's part of why they have different abilities too, like Rhino's one does not have any method for generating an outline or silhouette lines out to AI or PDF format like MoI's does.

I think it could be possible for me to increase the accuracy of MoI's one in the future, by incorporating some more detailed analysis of things when a curve is entering or exiting from the hidden state.

- Michael

---

Thanks for the explanation.
I like the idea of increasing the accuracy, if possible. Otherwise, for some technical drawings I am sticking to Rhino at the moment. It's not a problem. But the silhouettes+outlines output is really great for presenting a product quickly and clear.

---

Hi,

Thanks again for this amazing feature!

I also use it to extract renders only, having the alpha channel is a very productive asset.
I'm getting used to the megapixel concept, so for a squarish viewport, 4 mp gives me about 2000px which is often quite enough for my needs.

Marc

---

You're welcome Marc, I'm glad that you're putting it to good use!

- Michael

---

...And another reason why I'm loving this new PDF-writer feature more and more!




I had to write a short article for our local ham club newsletter: http://k4tlh.net/tars-newsletter/

So last night I came up with an idea to break down the anatomy of one of the type of Morse code (CW) key I use which is called a "Bug" by Amateur radio operators.

This is a WWII "J-36" "Bug" (Vibroplex type) key manufactured by J.H. Bunnell in 1942. The base is a heavy piece of solid cast iron, and the rest is nickel coated brass.
The swing arm is moved one way to act as a way to make manually sent dashes "dah's" and moving the arm the other way causes a pendulum to reverberated a spring-loaded contact to produce exact dots "dit's".
The weight on the reed determines the frequency and will give you about 150 dits if needed with the default configuration yielding dots at about 40 word-per-minute speeds.
I have an added weight called a "Bug Tamer" which brings it down to 18 wpm.

This type of key was mostly perfected and mass-marketed by a company called Vibroplex starting in 1904 and is still in business today, though the concept goes back to the old telegraph days in the 1800's.

Go to this site to see a nifty Flash animation of how this key works::: http://www.ae4rv.com/tn/education/bug.htm


Armed with only a small engineer's ruler, I transposed the measurements into a MoI model, outputted it to a PDF, then used Corel to do the rest.

Though I could have just used the PDF result, I tend to develop certain niches with styling, and after spending two decades of hand-drawing, scanning and tracing to vector - I'm partial to the results.

Nothing too noteworthy, but a very basic result that did the job when needed.

---

Show messages:  1-14  …  215-234  235-254  255-274  275-294  295-296