peter_spy
-
Posts
3201 -
Joined
-
Last visited
-
Days Won
109
Posts posted by peter_spy
-
-
-
-
-
-
-
In rotate mode it makes sense to stay in the same place, similar to what modeling apps do. In translate mode, not so much. It's kinda like with this toggleable option to turn off rotating an object using its pivot/origin. There's no point in having it off, as pivot point placement is a deliberate part of modeling, whether we're talking snapping modular meshes, deco props etc.
-
It's a default behavior in other editors I know, so having it on was like an obvious thing to me.
-
I'm not saying that it isn't useful, but doesn't DR automatically move the cloned entity one grid unit in two directions by default? I don't think I even had this problem, thanks to this feature. Can't speak for others though, obviously.
-
Saw his work back then, such exercises are very useful. If he wanted to break into the game industry, this project was a very decent proof that he's already a very promising generalist.
-
There's no point in introducing PBR if you're not doing it on correct data. Creating a simple scene in Unreal of Unity, and then using the same images and materials in TDM scene would give more meaningful results to compare.
-
Holy shit, fuck yeah! Finally!
Edit: All in all, it's a balancing act. While having thousands of tiny models in your visleaf will be bad, combining everything into large models can hurt performance too. If the model is bigger than what you can see in your POV, and there are lights hitting it and casting shadows, those addidional DCs and shadows will impact your performance, even if you don't see such lights.
-
Why using some Urine3d when you can have an industry standard that is Disney BRDF, which is also open source, IIRC?
-
Good thing that most maps run fairly well then, as this went unnoticed for quite some time, I think.
Still, the easy workaround for that would be either using doors or using proximity-triggered visportals. Try to place a func_portal so it touches the visportal for the visleaf where portalsky material is located, then set up dist_check_period and portal_dist values. That should do the trick.
-
Views is usually set at 3, if you have a regular scene without stuff like mirrors and such. This is the scene with second visportal open:
Now the second visportal is opened and "skybox" is visible. Note that number of views and texture memory used hasn't changed, so it was used by the skybox all along.
-
14 hours ago, Obsttorte said:
2.) sounds odd. I noticed when working with caulk sky in the past that the sky stopped rendering when there was no visportal textured surface in the currently rendered area (noticeable as the caulked surfaces suddenly turned from skybox to black). There have been adjustments made both to the vp's as to the way portal skies are rendered if I am not mistaken, so maybe something changed along those. Haven't touched DarkRadiand in a while (except for setting up scripts or custom objects, but no real mapping).
I'm still on 2.08, so maybe that has changed, but:
The portalsky surface is behind the visportal that is closed, but look at the stats.
-
1 hour ago, Obsttorte said:
I agree with what Dragofer posted. The skybox is only rendered when there is at least one surface within the currently rendered areas that has the portal_sky texture on it. This doesn't imply that this surface or the skybox as such is neccessarely visible. I am not sure what older engine version you are refering to, but it was always the case since I started working with the code, so I would assume for about 10 years at least. Actually I assume it was always like that.
To be more precise and in terms of actual mapping scenarios:
1) If you have a portalsky surface in a current visleaf, but it's not in your field of view – it still gets rendered.
2) If you have a series of visleafs divided with portals, but with no additional setup (like doors or func_portals that force portals to close) – skybox still gets rendered, even if you see portals as marked as closed in your debug view.
Only with portals that are forced to be closed by doors, func_portals and such, the portalsky skybox doesn't add to your performance stats and texture memory.
-
17 minutes ago, Dragofer said:
In my experience the skybox is only rendered when the player can see an area containing a portal_sky surface, you can see this when standing in a caulk-textured room and opening a door to a portal_sky-textured room. I don't know how GPU memory is handled, though.
I've been meaning to recheck that some time ago but I forgot. I remember looking at the stats in older engine versions, and the additional subview + DCs and other stuff for skybox were always there. It's cool if this had been taken care of though
-
5 hours ago, Petike the Taffer said:
I don't want to make a tall courtyard room with a skybox that kills the performance anytime the player goes outside. (And yes, I am using visportals everywhere, don't worry.)
As long as nothing has changed on this during developement lately, the skybox is a sort of subview that is always rendered by default (or at least it uses GPU memory), even when player's inside. This is info_portal sky, which acts as a virtual 360° camera.
If you want something more simple, you could just make a cubemap material and then apply in to 'ceiling' brushes for outside. Then it will be rendered only when you get outside, but its performance impact should be minimal.
-
1
-
-
FYI, speculars in Thief 3 were downright broken, that's why they weren't used. There was a specular slot in the materials, but I was never able to get a meaningful result there. That said, cubemaps were kinda broken as well. If you compare how cubemaps work here and in Thief 3, in TDM the reflection is modified by the normalmap, as it should. In Thief 3, it's sort of applied last, so it looks like a separate layer put on the top of diffuse and normalmap – unless you get rid of the diffuse texture. Then it gets modified by the normalmap, that's how they made the silver stuff for example.
But anyway, Thief 3 isn't really a good example of how materials should be used, that renderer was seriously broken and it's nothing short of a miracle that two games were made on it.
-
That technique didn't become widespread until parallax-corrected cubemaps and then Disney's BRDF solution became available. There were custom solutions, like for UE3 there was Remember Me game, but it only around UE4 we're talking about standards. Plus I guess hardware had to catch up as well.
-
1 hour ago, HMart said:
On that Doom 3 shots that nbohr1more posted, can someone explain to me how PBR can do such a stark diference in light levels?!
I can only assume the lighting setup was corrected to match textures that were adjusted for PBR. While non-pbr can use full 0-255 intensity range for diffuse (although it shouldn't), PBR base color needs to be between something like RGB 50 and 235.
-
Blend add mode is TDMs equivalent of emissive maps. I understood that totallytubular meant glass with cubemap reflection that is fairly bright, when put in area with ambient world only.
-
Interestingly enough, that was missing curly bracket in the material list section. Somehow that didn't bother DR at all. And yeah stuff like
Quote*MATERIAL_SHADING WHO CARES
is always fun. Fortunately, that doesn't impact the model at all
-
1
-
-
Having more controls over how water looks might be interesting, but automating tile floor reflections isn't a good idea IMO. As with most materials in non-pbr setup, you have to author specularity and cubemaps per your lighting setup. E.g. cubemap reflections look very pronounced in dark areas and washed out in intensely lit places. There's no one-size-fits-all solution to that.
-
1
-
Feature Discussion: Material Editor
in DarkRadiant Feedback and Development
Posted · Edited by peter_spy
.