qtpyhammer-devs / qtpyhammer Goto Github PK

yoshimario2000 reported occasionally Left-Right controls break (found to be related to spinning the camera too many times along local X axis

Exactol noted the cursor can escape the window during tracking

should be able to break off into it's own library (at some point)

When a QTimer is used for timing frames, either in the viewports or the demo player prototype, frames can lag

The error / deviation accumulates too.
We could look at the time taken to execute functions tied to the timer and compensate for the deviation

Or asynchronously run the functions with a 1 frame delay, showing the previous frame (double buffering) some kind of “delayed execution” QTimer subclass (GFrameTimer?) could be useful

the code for initialising the 3D viewport is bad.
please review & fix it

The current brush system doesn't have indices for the vertices calculated to represent displacements.
This is because displacements have a consistent pattern.
Meaning instanced draw calls & triangle strips are a potential optimisation available in this case.
However, this would require tracking the power of stored displacements and utilities.render.manager.find_gaps using this info to keep displacements of similar powers together.

Using a tesselation shader and uniform buffer to shape displacements would be a further optimisation, but adds a lot of complexity. (probably a very bad idea then)

it'd be crazy clever to store only the pattern of a power 2 and a power 3, then use some draw call magic to offset the indices to the start of each displacement in the vertex buffer, but that's also very complex and would likely take many months to work out, if it is at all possible.

For now, the index buffer entry for each displacement must be calculated at when organsing buffer writes (render.manager.add_brushes).

It's not interpolated, it can still be updated every 60/th of a second.
Just need to update utilities.camera to interpolate between it's last state and the latest state (update)
so refactor camera.set to take a value to interpolate by calculated from viewport.timer.remainingTime()

We need a way to select objects to apply operations to them.
Since we only have a 3D viewport at time of writing, raycasts seems like the way to go

This will need to work for brushes, displacements, faces & point entities

Work with whoever picks up #6 to ensure the interface to the selection is easy to work with

Full log:

Traceback (most recent call last):
  File "D:\repo\QtPyHammer\QtPyHammer\ui\core.py", line 37, in open_files
    def open_files(): ops.open_files(self, self.map_browser)
  File "D:\repo\QtPyHammer\QtPyHammer\ops\__init__.py", line 38, in open_files
    main_window.open(filename)
  File "D:\repo\QtPyHammer\QtPyHammer\ui\core.py", line 313, in open
    tab = workspace.VmfTab(filename, new=False, parent=self)
  File "D:\repo\QtPyHammer\QtPyHammer\ui\workspace.py", line 38, in __init__
    self.map_file = VmfInterface(self, self.filename)
  File "D:\repo\QtPyHammer\QtPyHammer\ops\vmf.py", line 17, in __init__
    self.hidden = self._vmf.hidden
AttributeError: 'Vmf' object has no attribute 'hidden'

Python version

(venv) D:\repo\QtPyHammer>python --version
Python 3.9.2

Installed package

(venv) D:\repo\QtPyHammer>pip list
Package    Version
---------- -------
cx-Freeze  6.1
fgdtools   1.0.1
future     0.18.2
numpy      1.18.5
pip        20.2.3
PyOpenGL   3.1.5
pyparsing  2.4.7
PyQt5      5.15.3
PyQt5-Qt   5.15.2
PyQt5-sip  12.8.1
setuptools 49.2.1
vmf-tool   0.1.0

The cursor is locked to the center of the screen at all times for moving the 3D view camera.
Valve's hammer uses a held key to switch to 3D camera motion.

Setting up OpenGL, adding a object to renderbuffers and changing shaders & vertex formats is very manual

most of the work of adding renderable objects to a viewport happens in render.py
with plenty of other code in ui.core doing setup, which it shouldn't have to

creating a viewport should be a simple as .setWidget(viewport())

viewport should have a "addBrush(...)" method
also we need tweakable GL settings and possibly even a system benchmark

create more specialised classes if nessecary
we do want to recycle viewports for the model browser at least

need to detect:

• $basetexture; which .vtf(s) does this .vmt use?
• $surfaceprop
• $blendmodulate
• proxies (angle, scroll, tint, etc.)

this info will be used for rendering & preview thumbnails
previews need to look close to in-game

cx_Freeze is still being updated.
f-man build system is still on python3.6 and it's dependencies are outdated & insecure.
f-man linux builds also didn't compile properly, with OpenGL crashing (something we can't afford to work around).

cx_Freeze is still multi-platform an allows for a simpler folder structure.
QtPyHammer being based on Qt means no changes in files between distributions,
supporting multiple OpenGL shader versions is simple enough.

Some prototyping / experimenting will be needed to see if it will work, but I suspect it will.
Moving should help on the path to reducing the overhead of concerns for working on the project
and get those prototypes back out there so we can get user feedback to give us direction and focus.

QtPyHammer needs a UI element to select textures and assign them to selected faces
See the project for a rough outline of what needs doing / is done already

work with @snake-biscuits to figure out how to attach the UI & tools to a selection
since they will be working on selecting in 3D for #7

Still in a very prototypey structure, breaking each tab into their own class will be handy for relocating these tabs throughout the UI

this could even lead to a design paradigm similar to blender’s UI panels system
Linking a global scope to UI elements linked to that scope, updating visually to match the active selection

an outliner and a “logic nodes” panel would be quite useful, and thinking about things in this way could really help lock the UI down into something more easily understood

Solids which only have some of their vertices defined fail to load

The 3D viewport renders over the file browser(s), maybe pausing the viewport when dialogs open would be helpful
Though for the entity / object properties dialog you'll want to see your changes update the viewport...

As you've probably seen with the arrival of pySourceSdk https://pysourcesdk.github.io/hub/
Fgdtools is now deprecated, the project has been moved over to ValveFGD https://pysourcesdk.github.io/ValveFGD/