2
$\begingroup$

I've recently been experimenting with the game engine and coming from exclusively using cycles there are a few things that I am trying to get used to. The most annoying of which I find is that when I run the game it uses the same shading as the viewport. This doesn't make sense to me since I am used to rendering being totally independent of viewport settings.

So, as I usually use solid shading in the viewport, if I want to see my materials I have to remember to switch to material viewport shading mode before hitting P. Is there a way to have it automatically switch the shading mode to material when I run the game and back to solid (or whatever else it was) when I Esc. out?

$\endgroup$
  • $\begingroup$ This might be a precautionary measure - a deliberate limitation to make sure that if material viewport shading is causing a crash for some reason, that the instant you go to into the BGE you won't be put into a shading mode that will crash for you immediately. I don't know much about the BGE (yet) but I believe it could be like Cycles viewport shading in that when you load your saved .blend viewport shading is always disabled, even if it was enabled when you saved the file. Just my theory. $\endgroup$ – Mentalist Oct 10 '15 at 12:41
  • $\begingroup$ You complain that that output of the BGE looks the same as the 3D view in Blender? The funniest thing I ever heard. Usually we got complains if the output does not match. --- No I do not think there is an option that automatically switches the display method. You might write you own little Python script that switches the method and starts the game. Then redirect <p> to your script. $\endgroup$ – Monster Oct 12 '15 at 4:50
  • $\begingroup$ @Monster Well, I am used to Cycles where in the viewport I can use solid shading to make it faster and less cluttered; but when I render it uses the actual materials assigned to the objects. But in the BGE I equate running the game with rendering in Cycles, so I am surprised when running the game uses the viewport shading. I'll see what I can do with a script, though my Python is pretty rusty. $\endgroup$ – PGmath Oct 12 '15 at 13:42
  • $\begingroup$ Please keep in mind, if the scene is slow in viewport, it will be slow in the game as well. I can't help on that script as I usually do not do Blender Python. $\endgroup$ – Monster Oct 13 '15 at 4:56
1
$\begingroup$

You could split the Start/Stop keys into separate press/release actions... So P engages Material Shading then starts the game; and Escape stops the game then (re)engages Solid Shading.

The devil's in the detail of course, ie. typing exactly the right stuff into User Preferences » Input » 3dView » Object Mode P to start the game engine need only be changed from Press to Release, but the two compound shading actions are best done with two new entries.

Put wm.context_set_enum and space_data.viewport_shade in the first two boxes of both; then, to engage Material Shading with the first new entry, set the Value to MATERIAL and assign key P as Press; and to (re)engage Solid Shading with the second new entry, set the Value to SOLID and assign key Escape as Release.

I tested this out & it works nicely but it's still a good idea to backup your hidden User Preferences file so you can reinstate it if things get messed up). Several blender.stackexchange threads cover this.

Also note that a key's standalone release action will be triggered if a combining modifier (Ctrl / Shift / Alt) is released first.

So modifiers need to 'lag' and be the last key up. Unless the modifier is an adapted normal key, in which case clean key release may require 'cover' from an invoked on-screen dialogue.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.