Add support for 3D/CAD file formats preview

[kerwin612]

#34775

[wxiaoguang]

I think we need a pure frontend "render plugin" mechanism

1. Register "fronend render plugin"
2. Plugin read page information (for example: file name)
3. If the plugin is able to render it, read the "raw" content, then replace the "fileview" element.

I don't think we should hard-code too many file types in backend.

[wxiaoguang]

IIRC it bloats the binary about 1MB

Can we introduce an config option?

For example:

• RENDER_PLUGIN_ONLINE_3D_VIEWER = https://public-js-cdn/....

[kerwin612]

From a user's perspective, I personally feel that direct integration is better than dynamic loading.
Because building and installation are one-time processes.
However, if we switch to dynamic loading, each time it might require dynamically loading 1MB of JavaScript.
Especially in the current Chinese network environment, sometimes even some external CDNs cannot be accessed, which would directly make the preview unavailable.

So I personally vote for integration.
Of course, the final decision is up to you.

[wxiaoguang]

However, if we switch to dynamic loading, each time it might require dynamically loading 1MB of JavaScript.

Not "each", only once, there is browser cahce.

Especially in the current Chinese network environment, sometimes even some external CDNs cannot be accessed, which would directly make the preview unavailable.

That's why a config option to let users choose, or deploy one locally.

---

If we build the renders into Gitea's binary, then it bloats the binary soon when we introduce more in the future.

[kerwin612]

I fully understand your original intention, but I think this still stems from the perspective of operators. From a user's point of view, such an option shouldn't exist (or there's simply no need for it at all) – the default provided to users should inherently be the optimal solution.

Of course, I recognize that Gitea, as an open-source platform, does have many "operator" users. Your original intention might be to allow them to choose freely, but personally, I wonder if such customization is getting too caught up in minor details?

Alright, I've shared my thoughts. It's up to you all. If adjustments are needed, I'll cooperate with the changes.

[wxiaoguang]

Share some of my thoughts:

There are different requirements for various kinds of files to render.

• Some are widely-used, for example: CSV, PDF, etc
• Some are only used by some of the users: asciidoc, asciicast, console, 3d models, etc. The percentage varies.

So the question is how to make Gitea have a stable and flexible design to satisfy more renders in the future. Then we have some choices:

1. Only make widely-used renders builtin, keep the release binary as small as possible.
2. Make all renders builtin, then we should have some estimation about the side effects, and how large the binary would be in the future.

I haven't got a clear picture of this feature at the moment. What do other maintainers think about?

[wxiaoguang]

No

[hiifong]

I think the memory hog is more the git command.

[wxiaoguang]

I think the memory hog is more the git command.

I don't understand what's the point or whether it is related to the topic.

[TheFox0x7]

That's a separate issue though and there's not much that can be done to limit it. Also it's (IMO) a very large issue for limited memory scenarios which is entirely of topic here.

I can't say I know a ton about this, but here point is that if you bloat the binary it had to be loaded and run each time hook runs which is a waste of resources - hope I got that right.
Honestly hook doesn't even have to have inits(not too sure about it though?) - it just needs to know where gitea is to do RPC.

---

Sorry for derailing the scope.

[wxiaoguang]

Honestly hook doesn't even have to have inits(not too sure about it though?)

In history, the "gitea hook" sub commands always do various init calls (including load assets), for example: var re = regexp.MustCompile, init() { ... }, etc

When I refactor existing code, usually I also rewrite these code to something like sync.OnceValue and void unnecessary init.

About the binary size affect, it's more complicated and it depends on some OS behaviors like virtual memory/mmap management, usually the binary content should be cached in OS's shared-memory area when it runs, but it's difficult to evaluate all cases (especially when the memory is limited in a container), I am not expert either so it's just a guess.

So I also agree that "if increasing the binary size brings enough benefits, let's do it", and I think "It's fine to make this render builtin".

[wxiaoguang]

Can we merge "initPdfViewer" into the new framework? I think it can also benefit from the new design.

[lunny]

When viewing .3ds file, there is a View Rendered icon. But when viewing .mp4 or other binary files, there is no such icon. Is that normal?

[kerwin612]

My suggestions:

1. When there are no tabs to switch (as shown in Figure 2 above), this tab switch can be directly hidden, because an isolated button seems to have no meaning and may also cause users to guess and misunderstand.
2. Is it necessary to skip the click event for the selected tab?

[wxiaoguang]

Feel free to make more improvements.

[hiifong]

I think a full screen preview of the 3d file is missing.

[kerwin612]

Feel free to make more improvements.

OK, I'll find time to improve it.

[kerwin612]

I think a full screen preview of the 3d file is missing.

Yeah, this is already in the plan.

[hiifong]

bim, dae,brep,igs,stp,ply,off,wrl,ifc,3mf file extensions are rendered as plain text.

Please make it as draft.

[wxiaoguang]

bim, dae,brep,igs,stp,ply,off,wrl,ifc,3mf file extensions are rendered as plain text.

Please make it as draft.

It is already supported. Including STL, see my comment.

This PR can't auto render them because there is no accurate detection yet.

In the future, if we have a better detection, then we can auto render them.

[wxiaoguang]

Feel free to make more improvements.

OK, I'll find time to improve it.

Merge this as-is and propose following up PRs, or switch to WIP to wait for more changes?

[kerwin612]

Feel free to make more improvements.

OK, I'll find time to improve it.

Merge this as-is and propose following up PRs, or switch to WIP to wait for more changes?

Merge it first. I'll submit a PR for other optimizations or adjustments later.

[wxiaoguang]

It is already supported. Including STL, see my comment.

This PR can't auto render them because there is no accurate detection yet.

In the future, if we have a better detection, then we can auto render them.

More details about the problem:

It needs more logic to make it overall right, we need to distinguish the ambiguous filename extensions. For example: "*.obj, *.off, *.step" might be or not be a 3D model file. So when it is a text file, we can't assume that "we only render it by 3D plugin", otherwise the end users would be impossible to view its real content when the file is not a 3D model.

[hiifong]

ref: https://www.spatial.com/glossary/what-is-an-stp-file

I've just checked for information on this, and the .step and .stp files are standard ISO file formats (ISO 10303-242:2014), and I think we can check from the contents of the file.

$ cat as1_pe_203.stp ISO-10303-21; HEADER; FILE_DESCRIPTION((''),'2;1'); FILE_NAME('AS1_PE_ASM','2008-09-04T',('mmeadows'),(''), 'PRO/ENGINEER BY PARAMETRIC TECHNOLOGY CORPORATION, 2008340', 'PRO/ENGINEER BY PARAMETRIC TECHNOLOGY CORPORATION, 2008340',''); FILE_SCHEMA(( 'AP203_CONFIGURATION_CONTROLLED_3D_DESIGN_OF_MECHANICAL_PARTS_AND_ASSEMBLIES_MIM_LF')); ENDSEC; DATA; #16=DIRECTION('',(0.E0,1.E0,0.E0)); #17=VECTOR('',#16,2.E1); #18=CARTESIAN_POINT('',(4.E1,-2.E1,-7.5E1)); #19=LINE('',#18,#17); ... #2874=REPRESENTATION('centroid',(#2872),#2841); #2875=PROPERTY_DEFINITION_REPRESENTATION(#2873,#2874); ENDSEC; END-ISO-10303-21;

[hiifong]

ref: https://www.spatial.com/glossary/what-is-an-stp-file

I've just checked for information on this, and the .step and .stp files are standard ISO file formats (ISO 10303-242:2014), and I think we can check from the contents of the file.

$ cat as1_pe_203.stp ISO-10303-21; HEADER; FILE_DESCRIPTION((''),'2;1'); FILE_NAME('AS1_PE_ASM','2008-09-04T',('mmeadows'),(''), 'PRO/ENGINEER BY PARAMETRIC TECHNOLOGY CORPORATION, 2008340', 'PRO/ENGINEER BY PARAMETRIC TECHNOLOGY CORPORATION, 2008340',''); FILE_SCHEMA(( 'AP203_CONFIGURATION_CONTROLLED_3D_DESIGN_OF_MECHANICAL_PARTS_AND_ASSEMBLIES_MIM_LF')); ENDSEC; DATA; #16=DIRECTION('',(0.E0,1.E0,0.E0)); #17=VECTOR('',#16,2.E1); #18=CARTESIAN_POINT('',(4.E1,-2.E1,-7.5E1)); #19=LINE('',#18,#17); ... #2874=REPRESENTATION('centroid',(#2872),#2841); #2875=PROPERTY_DEFINITION_REPRESENTATION(#2873,#2874); ENDSEC; END-ISO-10303-21; 

I don't want you to implement it in this pull request, but I want to provide some clues about it

[wxiaoguang]

And we can also use AI:

[silverwind]

I don't think this will look good on dark theme, you need different colors on dark theme, e.g. use getColor() from web_src/js/features/codeeditor.ts to get the color values from CSS variables. Likely declare new color variables.

[kerwin612]

Thank you for pointing it out. I will improve it later.

[silverwind]

For the background, you can likely re-use --color-code-bg, e.g. getColor('--color-code-bg'), converting to this OV.RGBAColor of course.