(SOLVED) Giant pacman doesn't play nicely with compile :<

Legendoniance

L1: Registered
Apr 15, 2020
14
1
Hello!

===
FINAL EDIT:

Issue solved with the lights issue.
The texture passtime/neons/neon_yellow generates light and kills compiling when used on a big brush *shrug*

===
EDIT:
I separately put one pacman into a map, wrapped a skybox around it and compiled in 3 stages, and here's what I found:

1) BSP:
Perfect, <1 second

2) VIS:
Surprisingly good, at around 1-2 seconds
(looks like func_detail saved this?)

3) RAD:
Atrociously horrible, at about 5 minutes, I think?


Looking at the compile log added below, there's this:
38465 patches after subdivision
17251 direct lights
BuildFacelights: 0...1...2...3...4...5...6...7...8...9...10 (212)
too many lights 8193 / 8192

8193 lights???

===

I've got an idea for a dodgeball map, where players basically stand in the mouths of giant pacmans, and fight from there.

The idea is to make spheres (O), then cut into the sphere in a (<) or (>) way, for the shape of the mouth.

I've not worked with spheres before, and I don't know how I can replicate this.

Based on my little research, I've found that there are two ways to make spheres, one using the sphere brush and another using displacements.

I've tried both, and tried cutting into both, but they don't work or come up with stupid results.

1) Sphere brush: the brush was solid with multiple faces that couldn't be separated, and cannot be cut or clipped. I tried hollowing it out, which separated all the faces, but cutting it produces weird warped results, even when I manually cut each piece.

2) Displacements: like above, cutting it makes the pieces very weird and warped, but it's extra bad as the insides of the sphere has no texture. Trying to hollow it out creates a satanic block of matter.

Anyone can point me in the right direction, or tell me how I can achieve this?

Thanks in advance!
 

Attachments

  • tfdb_pacman backup.vmf
    570.4 KB · Views: 88
Last edited:

Pinewabble

L2: Junior Member
Dec 22, 2015
50
64
I guess you could use the forbidden art of carving to separate sphere top from another and then duplicate it and turn it slightly.
but personally i would just make a custom model, cus' carving can be bit janky and weird

also are the pacmans going to move or just stay stationary?
 

Attachments

  • upload_2020-5-28_16-2-24.png
    upload_2020-5-28_16-2-24.png
    287.9 KB · Views: 159

Legendoniance

L1: Registered
Apr 15, 2020
14
1
They'll be stationary, just 2 huge ones, one for each team.

The screenshot you have looks a little weird to me, as rotating the top half adds extra height.

The idea is to preserve the same height while chopping off an area for its mouth
 

Legendoniance

L1: Registered
Apr 15, 2020
14
1
Okay so I've created two simple pacmen by using a very thin rectangular brush to carve the two halves of a sphere, then rotated the top half in its place to make the mouth of the pacman.

To counter the extra height problem, I placed the top half within the bottom half, so that height = length = width, like a normal sphere.

HOWEVER, it does not compile. I stripped everything down in the map to just 1 pacman, and it does not want to cooperate at all.

I'm thinking this method is impossible? I don't understand how spheres/carving can cause major issues, but from the looks of it, if 1 pacman doesn't compile nicely, 2 pacmen definitely will kill itself.

I've attached the vmf file below, if anyone wants to help me take a look?

At the moment I'm out of ideas and any help is appreciated.
 

Attachments

  • tfdb_pacman backup.vmf
    570.4 KB · Views: 76

Legendoniance

L1: Registered
Apr 15, 2020
14
1
My map ideas have all been tiny ones or little modifications to existing maps, as a plan to start small.
Choosing to start with dodgeball maps has been fun as it allowed me to express some creativity without a giant map (since db maps are tiny), and I've made 2 finished maps.

So I've never had to look into func_detail. I knew what it was and a rough idea of how it cuts off visibility and saves processor power and stuff for visleafs.

I separately put one pacman into a map, wrapped a skybox around it and compiled in 3 stages, and here's what I found:

1) BSP:
Perfect, <1 second

2) VIS:
Surprisingly good, at around 1-2 seconds
(looks like func_detail saved this?)

3) RAD:
Atrociously horrible, at about 5 minutes, I think?


Looking at the compile log added below, there's this:
38465 patches after subdivision
17251 direct lights
BuildFacelights: 0...1...2...3...4...5...6...7...8...9...10 (212)
too many lights 8193 / 8192

What the heck?

Since it's RAD (Google tells me RAD deals with light and bouncing of it), I went ahead to check if I have:
1) leaks (everything is nicely wrapped in a box of skybox); or
2) lights (I have 0 lights in it!); or
3) satan hiding somewhere (probably)

Any clues?


** Executing...
** Command: "C:\Program Files (x86)\Steam\steamapps\common\Team Fortress 2\bin\vbsp.exe"
** Parameters: -game "C:\Program Files (x86)\Steam\steamapps\common\Team Fortress 2\tf" "C:\Users\markl\Desktop\tf2 mapwork\tfdb_pacmen.vmf"
Valve Software - vbsp.exe (Sep 23 2019)
12 threads
MSG_FILEWRITE - Filesystem was asked to write to 'C:\Users\markl\Desktop\tf2 mapwork\tfdb_pacmen.log', but we don't own that location. Allowing.
materialPath: C:\Program Files (x86)\Steam\steamapps\common\Team Fortress 2\tf\materials
Loading C:\Users\markl\Desktop\tf2 mapwork\tfdb_pacmen.vmf
ConVarRef mat_reduceparticles doesn't point to an existing ConVar
fixing up env_cubemap materials on brush sides...
ProcessBlock_Thread: 0...1...2...3...4...5...6...7...8...9...10 (0)
ProcessBlock_Thread: 0...1...2...3...4...5...6...7...8...9...10 (0)
Processing areas...done (0)
Building Faces...done (0)
Chop Details...done (0)
Find Visible Detail Sides...
Merged 22 detail faces...done (0)
Merging details...done (0)
FixTjuncs...
PruneNodes...
WriteBSP...
done (0)
writing C:\Users\markl\Desktop\tf2 mapwork\tfdb_pacmen.prt...Building visibility clusters...
done (0)
Creating default LDR cubemaps for env_cubemap using skybox materials:
skybox/sky_day01_01*.vmt
! Run buildcubemaps in the engine to get the correct cube maps.
Creating default HDR cubemaps for env_cubemap using skybox materials:
skybox/sky_day01_01*.vmt
! Run buildcubemaps in the engine to get the correct cube maps.
Finding displacement neighbors...
Finding lightmap sample positions...
Displacement Alpha : 0...1...2...3...4...5...6...7...8...9...10
Building Physics collision data...
done (0) (28063 bytes)
Placing detail props : 0...1...2...3...4...5...6...7...8...9...10
Compacting texture/material tables...
Reduced 28 texinfos to 14
Reduced 5 texdatas to 5 (121 bytes to 121)
Writing C:\Users\markl\Desktop\tf2 mapwork\tfdb_pacmen.bsp
MSG_FILEWRITE - Filesystem was asked to write to 'C:\Users\markl\Desktop\tf2 mapwork\tfdb_pacmen.bsp', but we don't own that location. Allowing.
Wrote ZIP buffer, estimated size 105889, actual size 105675
0 seconds elapsed

** Executing...
** Command: "C:\Program Files (x86)\Steam\steamapps\common\Team Fortress 2\bin\vvis.exe"
** Parameters: -game "C:\Program Files (x86)\Steam\steamapps\common\Team Fortress 2\tf" "C:\Users\markl\Desktop\tf2 mapwork\tfdb_pacmen"
Valve Software - vvis.exe (Sep 23 2019)
MSG_FILEWRITE - Filesystem was asked to write to 'c:\users\markl\desktop\tf2 mapwork\tfdb_pacmen.log', but we don't own that location. Allowing.
12 threads
reading c:\users\markl\desktop\tf2 mapwork\tfdb_pacmen.bsp
reading c:\users\markl\desktop\tf2 mapwork\tfdb_pacmen.prt
60 portalclusters
104 numportals
BasePortalVis: 0...1...2...3...4...5...6...7...8...9...10 (0)
PortalFlow: 0...1...2...3...4...5...6...7...8...9...10 (0)
Optimized: 0 visible clusters (0.00%)
Total clusters visible: 3600
Average clusters visible: 60
Building PAS...
Average clusters audible: 60
visdatasize:1444 compressed from 960
writing c:\users\markl\desktop\tf2 mapwork\tfdb_pacmen.bsp
MSG_FILEWRITE - Filesystem was asked to write to 'c:\users\markl\desktop\tf2 mapwork\tfdb_pacmen.bsp', but we don't own that location. Allowing.
0 seconds elapsed

** Executing...
** Command: "C:\Program Files (x86)\Steam\steamapps\common\Team Fortress 2\bin\vrad.exe"
** Parameters: -game "C:\Program Files (x86)\Steam\steamapps\common\Team Fortress 2\tf" "C:\Users\markl\Desktop\tf2 mapwork\tfdb_pacmen"
Valve Software - vrad.exe SSE (Sep 23 2019)
Valve Radiosity Simulator
12 threads
MSG_FILEWRITE - Filesystem was asked to write to 'c:\users\markl\desktop\tf2 mapwork\tfdb_pacmen.log', but we don't own that location. Allowing.
[Reading texlights from 'lights.rad']
unknown light specifier type - lights
[56 texlights parsed from 'lights.rad']
Loading c:\users\markl\desktop\tf2 mapwork\tfdb_pacmen.bsp
Setting up ray-trace acceleration structure... Done (0.05 seconds)
505 faces
3577562 square feet [515168928.00 square inches]
0 Displacements
0 Square Feet [0.00 Square Inches]
505 patches before subdivision
38465 patches after subdivision
17251 direct lights
BuildFacelights: 0...1...2...3...4...5...6...7...8...9...10 (212)
too many lights 8193 / 8192

** Executing...
** Command: Copy File
** Parameters: "C:\Users\markl\Desktop\tf2 mapwork\tfdb_pacmen.bsp" "C:\Program Files (x86)\Steam\steamapps\common\Team Fortress 2\tf\maps\tfdb_pacmen.bsp"
 

Legendoniance

L1: Registered
Apr 15, 2020
14
1
After an hour and a half, finally found the issue!

The texture I used was passtime/neons/neon_yellow.

That texture apparently generates light (?) and is blindingly bright in game, without any other lights and with mat_fullbright 0.

Not sure how textures generate light but oh well...*shrug*