I created a .obj model by Blender on Windows10 and send it to an computer using MacOS.
When I tried to open the .obj model,some of its faces seem to disappear.But when I turned to other directions,the absent faces appeared but some other faces disappear.
Could some one tell me why this happened and how can I fix it?Thank you a lot!
The same thing happened to me on windows 10, I read that the solution was to use the triangulate modifier in blender before exporting, and everything worked perfectly for me. Something about some programs need triangles for mesh compatibility
Related
I have created a pdf viewer using react-pdf. When I display certain pdfs, the text is choppy and unreadable. I have tried zooming in and out of the document and it is choppy in different ways at different scales. Sometimes the text even looks okay at a certain scale after zooming out and then zooming back in.
(Sample at 1.5 scale)
(Sample at 1.6 scale)
At first, I thought it might be an issue with react-pdf, but I saw that react-pdf is basically a wrapper around PDF.js. I found that I can replicate the issue in the PDF.js demo page.
Unfortunately, I'm working with a pdf that contains identifying information, so I can't share the full pdf or full screenshot. I'll include as much as I can figure out to share.
What I have tried
My initial thought was that maybe the component was rendering small initially and then had issues scaling up. So I made the initial size really large, but that didn't fix it.
I made sure that standard fonts were included following the instructions on the react-pdf home page
I tried using pdf repair tools online to maybe fix the pdf itself. That didn't help.
I tried changing the renderMode to 'svg' as detailed in the Document api documentation. This was the most helpful fix, as it does render the text correctly, but it then makes it so the images on the pdf don't load.
Thanks for your help/suggestions.
If I can find a way to edit the pdf to not have sensitive information, I'll try to find a place to make it available for testing. I apologize that I cannot provide that at this time. I know it's difficult to give advice when you can't replicate it yourself. I'll work on that.
From a programming point of view there is only "Providing a standardFontDataUrl and disabling the font face" (see later), however it affects many pdf.js based code developers outputs, thus I consider as still "OnTopic"
This issue is still open in react-pdf, though I have seen it mentioned by other pdf.js users since mid year (MS or Chrome update ?) , so unsure if it is not a wider fail affecting Mozilla PDF.js code users.
https://github.com/wojtekmaj/react-pdf/issues/1010
https://github.com/wojtekmaj/react-pdf/issues/1025
There semes to be earlier reports back in Early March and then later suggestions to change win 10 drivers. However also reported by win 11 Pro users. PDF.js versions from 2.8.335 to 2.14.305, and it doesn't affect version 2.7.570. so partially down to updated versions ! But seen only in Chromium.
It is entirely possible that we started doing something that trips Chrome,
The symptoms seem to be hardware or settings orientated since it is reportedly seen on some identical groups of users but not affecting others.
toggling back and forth between single page and multi-page views the issue resolves. It also seems dependent on the resolution or appears on some machines and not others so it is a little tricky to repro.
I am not getting it personally, but a guy in my team get it.
Unclear which browsers are affected but looks like its a chromium / web kit rendering bug ?
Several browsers have been tested and only chrome faces this.
My colleague gets the same in Edge Version 101.0.1210.47 (Official build) (64-bit) and Brave (1.38.118 Chromium 101.0.4951.67) Will edit the issue
The suggested workaround is :-
Providing a standardFontDataUrl and disabling the font face fixes the issue.
if we disable Accelerated 2D canvas in chrome://flags then the preview appears nice and okay. But since this flag is on by default so user see the pixelated preview. Unless we ask them to turn off this flag.
Figured out that this only happens when hardware acceleration is enabled in your Chrome settings.
When its turned off the issue does not happen.
In address bar paste chrome://gpu or edge://gpu etc (its a long report of current onboard fixes) in my case (currently unconfirmed via reboot for my Edge) is showing Accelerated 2D canvas is unavailable: either disabled via blocklist or the command line. Disabled Features: 2d_canvas, thus I cannot see problems.
To change setting you can use
chrome://flags/#disable-accelerated-2d-canvas
but its a manual choice between options.
so on reboot I see
Graphics Feature Status
Canvas: Hardware accelerated
Canvas out-of-process rasterization: Disabled
but have little problem with the domo (except normal fuzzy text as pixels) so either Edge update or my hardware is not visibly affected or my default settings are reasonable.
This issue has been finally fixed in the latest version of react-pdf library. Check here: https://github.com/wojtekmaj/react-pdf/releases/tag/v6.2.2
I also faced the same error and I fixed it by setting render mode to canvas (earlier it was SVG) and scale value to more than 1. Try scale = 1.5
I am trying to export my application as eclipse product which works. In the end I want to create a classical installer, probably using EclipseNSIS (never used before).
In my config.ini.product-file I have listed all BMP-files which eclipse should use as launcher icon. The problem is that eclipse only uses the 16x16 8-bit icon. When I create a desktop shortcut the icon looks like a mess because I had to scale it down.
Is it somehow possible to tell eclipse to use the bigger versions of the BMP-files, like the 32x32 32-bit one?
I haven't tried EclipseNSIS yet because I still try to solve this while only exporting as eclipse product. Is it maybe possible in EclipseNSIS to use one of the bigger versions?
I had to make myself an .ico-file using GIMP. Using this .ico-file, the image looks fine. Using seperate icons it seems that it is only possible to use the 16x16 8-bit version.
I have a strange problem happening intermittently with my apps where textbox controls would disappear intermittently. I have narrowed the cause of this down to having image files (small logos etc) on my page.
I have managed to create a simple project which contains an xaml page with an image and 2 textblocks (these are in grids).
I have found on two test tablets that I can re-create the problem by going to task manager and creating a dump file for the running app.
After I do this twice and resume the app, the two textblocks disappear.
This exact problem is happening intermittently in my live apps.
Has anyone any ideas why this might be happening or what I should try next? I have no idea why creating a dump file forces the issue.
You can see a video of me re-creating the issue here:
https://onedrive.live.com/redir?resid=DF2BE823348DEA6C!74381&authkey=!AIvSU05r0363S3Y&ithint=video%2cMOV
The test project in the video can be downloaded from here:
https://onedrive.live.com/redir?resid=DF2BE823348DEA6C!74382&authkey=!AIGHSdezFcCbEZQ&ithint=file%2czip
So far I can re-create it with the exact same steps on my two different tablets - both running Windows 8.1 Pro 32bit.
If you are familiar with sideloading apps and you have a 64bit tablet I would be really appreciative if someone was able to test out the exact same steps as seen in the video.
Any help would be extremely appreciated as I am clueless as to where to go next.
I finally got to the bottom of this. The problem was down to the intel graphics driver that was installed on the tablets.
An updated driver was released around April which seemed to resolve the issue.
I have observed this problem of disappearing controls on views that do not contain image files but rather a background image. After reading your method of how to reproduce the issue, I've since removed the background image and replaced with a LinearGradientBrush and retested with the dump file process. The problem seems to have disappeared. (I'm running 32-bit as well.)
Not sure why, but some of the icons on the fontawesome cheatsheet can't be pasted into photoshop for use in mock-ups. I've installed the otf font.
cheatsheet is here
http://fortawesome.github.io/Font-Awesome/cheatsheet/
I can't paste this icon fa-plus-square-o #xf196;
I have a screenshot of what it looks like in photoshop but I can't post it because I don't have enough reputation on this site...
It won't let me change the font from Myriad to fontawesome, very strange because it works for other icons and I've been using it for a while and never had this problem...
I don't know why it's not working for you... I tried to copy and it works perfectly. Maybe you have an old version of the font. Try to reinstall it, and then copy the icon.
I'm a German user and had the same problem from one day to the other. In the past everything worked fine.
After a long searching in the web I went to settings => text. Here I unchecked "Show names in English language". Now it works. Maybe an installation of a Photoshop Elements action could have caused the problem. I dont'n know.
Before I found this solution I installed the most recent icon font file and started windows again. This did not help.
My suggestion: Play with the settings.
Bit late... but just in case it helps anyone else who runs into the same issues.
I ran into the issue earlier and couldn't figure out why it wasn't working as expected. Similar to one of the other answers, I think it was due to me having an older version that didn't include the icons I was trying to use. I downloaded the latest file, updated it, rebooted Photoshop and that's done the trick for me.
UPDATE: I wrote to Wolfram support about this and will update the post if they can resolve the problem. Sorry for spamming SO with a technical support question, but here it remains in case anyone else is having the same issue.
Is anyone else having this problem with Mathematica 8? I recently upgraded and noticed that when I export Graphics to a PDF file, although the file appears fine on my computer, it prints as a blank page. For example, try
Rectangle[{1,1}]//
Graphics//
Export["~/test.pdf",#]&
which creates a PDF file containing a black square. This file opens fine, but if I send it to my department printer I just get a blank page. If I don't export the graphics but print the notebook from MM, no problem, the graphics print as expected. If I use MM 7 to do exactly the same thing, the PDF file prints as expected. Exporting to PNG in MM8 seems to work fine. And, using the context menu Save Graphics As ... or File > Save Selection As ... to create a PDF containing just the graphic also works. However, these graphics eventually get included in a TeX document, and it would be far better if I could continue using the script I've got that doesn't require any button clicking to generate them.
I'm running MM 8.0.0.0 on Mac OS 10.6.7. I have not been able to test this on another printer yet, but this printer has never given me problems before and prints other PDF documents fine. Any ideas why this is happening?
Wolfram Research responds:
...
This issue has been reported by other users as
well and our developers are currently looking into it. I have added your
details to the report so you can be notified when this is resolved.
In the meantime, the alternatives that you could try are:
Try a different printer.
Rasterize the image with the function 'Rasterize' before exporting. If
the rasterized image loses some resolution, you could use the option
'ImageResolution' to edit this.
Rasterize[image, ImageResolution -> xxx]
Surely this is a bug (please report it to support#wolfram.com), but you can work around the problem by selecting the graphic and choosing File > Save Selection As... from the menu (or Save Graphic As... from the contextual menu). This produces a slightly different file that doesn't appear to exhibit the undesirable behavior we observe from Export[].
These problematic files, and LaTeX PDFs that include them, can be properly printed by Adobe Reader 10.1.2. That's if you're okay with installing and using a 450MB PDF reader.
I reproduced the problem (leading me to this question) with Mathematica 8.0.4.0 on Mac OS X 10.7.2. Wolfram suggested lame workarounds like Rasterize and told me
This issue has been addressed by our developers, and a fix will be included in a future version of Mathematica.