Oh, I thought it might be local ran. If it needs to access external server it may be my security settings. Works with VS Code. It installs and sets up the needed configuration. Thank you.
Thanks for the model — it actually revealed an interesting issue in the HTML3D viewer.
When I exported it, I noticed rendering artifacts on some of the very thin wall assemblies. The surfaces are extremely close to each other, and the HTML/WebGL viewer was losing depth precision, causing Z-fighting between them.
SketchUp handles this case correctly, but my viewer was using camera depth settings that were too broad for this kind of geometry.
I’ve now made a test fix by improving the WebGL depth precision, using a logarithmic depth buffer and adapting the camera near/far clipping range to the actual size of the model.
So this test was really useful — it exposed a case I hadn’t encountered with my own models and led to an improvement that I’ll include in the next release.
This is exactly the kind of feedback I’m hoping to get from the community: different models, different use cases, unexpected issues, and real-world tests that can help me improve the exporter.
I’ll post the updated result once I’ve finished testing the fix.
I’ll be sure to test this out.
Per your mentioning in this thread: file size is the issue, especially with textured models. I’ve been building workflows to reduce the final file size of 3D models that I then insert into PDFs via the SimLab PDF exporter plugin (which works great) but because my models begin with mesh models created via photogrammetry, I need to reduce textured face count and then get the texture back onto the model, hence the workflows.
The final deliverable: a 3D model that others can use without the need for any new software is the key here for sure, and an HTML approach is a great idea.
Yes, the cladding is probably only 0.25" thick, don’t quote me on that. If your exporter/viewer can handle a typical mdkBIM model (ie. Medeek foundation, floor, wall and roof assemblies) then you are probably within the realm of a very workable pipeline.
I am curious as to the size of this model once it is converted to HTML 3D how much does it grow in size?
My interest in 3D PDFs goes all the way back to the first ones I saw around 2006. I was genuinely fascinated by them, and that’s actually what got me started with JavaScript through Adobe’s 3D API.
A few years later, I developed my first SKP-to-3D-PDF converter, which is still available at webgl.tarn.us. After that, I started looking for a more modern and accessible format, and that’s what eventually led me to WebGL and the HTML3D converter.
Most of the development is driven by my own work. I work in an engineering office within the sugar industry, and I’m probably my own biggest user. Real-world industrial projects are what keep pushing these tools forward.
As for your 3D PDFs, I’m sure you’ve run into the same issue I did many times: “You need to open it with Acrobat Reader, otherwise it won’t work!”
That’s exactly the kind of limitation I want to eliminate with HTML3D. I want to keep the same idea of portability that made 3D PDFs so appealing in the first place: a single file that anyone can open directly in a web browser, with no special software to install.
That’s really the guiding principle behind HTML3D, and I want to stay true to it as the project evolves.
it’s 3700ko
garag2630_.zip (1.0 MB)
I tested the app, and it’s definitely superior to mine. One small suggestion would be to keep edges off by default. I tested it with a 100 MB file, and performance became noticeably slower with edges turned on.
Funny, because in the energy and infrastructure industry a PDF is kind of a relief for a lot of the engineers I work with. They are used to Bluebeam but are open to Acrobat Reader which is already installed on their machines. The reason I started exploring this area was because I’m always surprised how many engineers aren’t CAD people. Like, that’s the whole reason I became an engineer!!!
that’s very true’ been doing the cad from the start’ and agree many are the way you describe
I agree, and even better than a whirling circle perhaps a progress bar would be even better. If it takes that long to load many users will simply think the web page has timed out and abort.
If you want to make a SketchUp v2017 release of your addon, I have a traceback of your code.
Your idea is amazing, I love! At soon in DM may be…
That would definitely be useful, especially with very large files. For the Free version though, I’m trying to keep the plugin and the generated HTML as simple as possible.
I’ll keep it in mind, but simplicity is really the priority for this free version.
Thanks for testing it! You can actually choose whether the edges are displayed or not when the HTML opens.
Which SketchUp version are you using? The slowdown could also come from the browser using the integrated GPU instead of the dedicated GPU. I’ve also noticed that GLB export with SU2022 isn’t as well optimized as with later versions.
It would be interesting to know your SketchUp version and GPU.
Hi Richard,
I don’t know much about Dynamic Components, to be honest. If you could share this component with me, I’d be happy to take it apart and see what’s causing the issue.
If I can reproduce it and find the problem, I should be able to release a fix.
By the looks of it, this isn’t really designed for SketchUp users themselves, but for their customers to view the models. In that case, a loading indicator might actually be more important. It lets the customer know the model is still loading instead of leaving them wondering whether something has gone wrong. Just a thought.
Never ever before I downloaded an extension to test it and used it 10 minutes after that. Incredible easy and fast! Respect!
This is a really useful tool! I like that the SketchUp model can be shared as one HTML file and opened without SketchUp or the internet. The PLY point cloud option is also a great feature. Nice work!